Re: [patch] mm: thp: disable defrag for page faults per default

[Mel Gorman]

On Mon, Jul 25, 2011 at 10:38:41PM +0200, Johannes Weiner wrote:
> With defrag mode enabled per default, huge page allocations pass
> __GFP_WAIT and may drop compaction into sync-mode where they wait for
> pages under writeback.
> 
> I observe applications hang for several minutes(!) when they fault in
> huge pages and compaction starts to wait on in-"flight" USB stick IO.
> 
> This patch disables defrag mode for page fault allocations unless the
> VMA is madvised explicitely.  Khugepaged will continue to allocate
> with __GFP_WAIT per default, but stalls are not a problem of
> application responsiveness there.
> 

Seems drastic. You could just avoid sync migration for transparent
hugepage allocations with something like the patch below? There still
is a stall as some order-0 pages will be reclaimed before compaction
is tried again but it will nothing like a sync migration.

=== CUT HERE ===
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1fac154..40f2a9b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2174,7 +2174,14 @@ rebalance:
 					sync_migration);
 	if (page)
 		goto got_pg;
-	sync_migration = true;
+
+	/*
+	 * Do not use sync migration for transparent hugepage allocations as
+	 * it could stall writing back pages which is far worse than simply
+	 * failing to promote a page.
+	 */
+	if (!(gfp_mask & __GFP_NO_KSWAPD))
+		sync_migration = true;
 
 	/* Try direct reclaim and then allocating */
 	page = __alloc_pages_direct_reclaim(gfp_mask, order,
=== CUT HERE===

As this is USB, the rate of pages getting written back may mean that
too much clean memory is reclaimed in direct reclaim while compaction
still fails due to dirty pages. If this is the case, it can be mitigated
with something like this before calling direct reclaim;

if ((gfp_mask & __GFP_NO_KSWAPD) && compaction_deferred(preferred_zone))
	goto nopage;

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/