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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>