mm-thp-avoid-excessive-compaction-latency-during-fault.patch excludes sync
compaction for all high order allocations other than thp. What we really
want to do is suppress sync compaction for thp, but only during the page
fault path.
Orders greater than PAGE_ALLOC_COSTLY_ORDER aren't necessarily going to
loop again so this is the only way to exhaust our capabilities before
declaring that we can't allocate.
Reported-by: Hugh Dickins <hughd@xxxxxxxxxx>
Signed-off-by: David Rientjes <rientjes@xxxxxxxxxx>
---
mm/page_alloc.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2585,16 +2585,13 @@ rebalance:
if (page)
goto got_pg;
- if (gfp_mask & __GFP_NO_KSWAPD) {
- /*
- * Khugepaged is allowed to try MIGRATE_SYNC_LIGHT, the latency
- * of this allocation isn't critical. Everything else, however,
- * should only be allowed to do MIGRATE_ASYNC to avoid excessive
- * stalls during fault.
- */
- if ((current->flags & (PF_KTHREAD | PF_KSWAPD)) == PF_KTHREAD)
- migration_mode = MIGRATE_SYNC_LIGHT;
- }
+ /*
+ * It can become very expensive to allocate transparent hugepages at
+ * fault, so use asynchronous memory compaction for THP unless it is
+ * khugepaged trying to collapse.
+ */
+ if (!(gfp_mask & __GFP_NO_KSWAPD) || (current->flags & PF_KTHREAD))
+ migration_mode = MIGRATE_SYNC_LIGHT;
/*
* If compaction is deferred for high-order allocations, it is because
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>