On Thu, Jun 06, 2013 at 10:11:48AM +0100, Mel Gorman wrote: > That was part of a series that addressed a problem where processes > stalled for prolonged periods of time in compaction. I see your point Yes. > and I do not have a better suggestion at this time but I'll keep an eye > out for regressions in that area. That's my exact concern too, and there's not much we can do about it. But not calling compaction reliably, simply guarantees spurious failures where it would be trivial to allocate THP and we just don't even try to compact memory. Of course we have khugepaged that fixes it up for THP. But in the NUMA case (without automatic NUMA balancing enabled), the transparent hugepage could be allocated in the wrong node and it will stay there forever. In general it should be more optimal not to require khugepaged or automatic NUMA balancing to fix up allocator errors after the fact, especially because they both won't help with short lived allocations. And especially the NUMA effect could be measurable for short lived allocations that may go in the wrong node (like while building with gcc). -- 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>