On 09/23/2016 10:26 AM, Michal Hocko wrote: >> include/linux/compaction.h | 5 +++-- >> mm/compaction.c | 44 +++++++++++++++++++++++--------------------- >> mm/internal.h | 1 + >> mm/vmscan.c | 6 ++++-- >> 4 files changed, 31 insertions(+), 25 deletions(-) > > This is much more code churn than I expected. I was thiking about it > some more and I am really wondering whether it actually make any sense > to check the fragidx for !costly orders. Wouldn't it be much simpler to > just put it out of the way for those regardless of the compaction > priority. In other words does this check makes any measurable difference > for !costly orders? I've did some stress tests and sampling /sys/kernel/debug/extfrag/extfrag_index once per second. The lowest value I've got for order-2 was 0.705. The default threshold is 0.5, so this would still result in compaction considered as suitable. But it's sampling so I might not got to the interesting moments, most of the time it was -1.000 which means the page should be just available. Also we would be changing behavior for the user-controlled vm.extfrag_threshold, so I'm not entirely sure about that. I could probably reduce the churn so that compaction_suitable() doesn't need a new parameter. We could just skip compaction_suitable() check from compact_zone() on the highest priority, and go on even without sufficient free page gap? -- 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>