On Fri, 11 Nov 2011, Mel Gorman wrote: > > Indeed. It seems like the behavior would better be controlled with > > /sys/kernel/mm/transparent_hugepage/defrag which is set aside specifically > > to control defragmentation for transparent hugepages and for that > > synchronous compaction should certainly apply. > > With khugepaged in place, it's adding a tunable that is unnecessary and > will not be used. Even if such a tuneable was created, the default > behaviour should be "do not stall". > Not sure what you mean, the tunable already exists and defaults to always if THP is turned on. I've been able to effectively control the behavior of synchronous compaction with it in combination with extfrag_threshold, i.e. always compact even if the fragmentation index is very small, for workloads that really really really want hugepages at fault when such a latency is permissable and then disable khugepaged entirely in the background for cpu bound tasks. 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? -- 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>