Re: [PATCH] mm: Do not stall in synchronous compaction for THP allocations

[Andrea Arcangeli <aarcange@redhat.com>]

On Fri, Nov 11, 2011 at 02:39:10AM -0800, David Rientjes wrote:
> The history of this boolean is somewhat disturbing: it's introduced in 
> 77f1fe6b back on January 13 to be true after the first attempt at 
> compaction, then changed to be !(gfp_mask & __GFP_NO_KSWAPD) in 11bc82d6 
> on March 22, then changed to be true again in c6a140bf on May 24, then 
> proposed to be changed right back to !(gfp_mask & __GFP_NO_KSWAPD) in this 
> patch again.  When are we going to understand that the admin needs to tell 
> the kernel when we'd really like to try to allocate a transparent hugepage 
> and when it's ok to fail?

Sorry for the confusion but it was reverted by mistake. Mel fixed a
compaction bug that caused stalls of several minutes to
people. compaction was overflowing into the next zone by mistake
without adjusting its tracking parameters. So it wasn't clear anymore
if sync compaction was really a problem or not. So I reverted it to be
sure. And well now we're sure :). Without USB or pathologically slow
I/O apparently it's not a noticeable issue.

So having sync compaction off by default sounds good to me.

We can still add a tunable to force sync compaction in case anybody
needs.

Another topic is if slub and stuff also wants sync compaction off by
default when they allocate with large order so triggering compaction.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>