Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions
From: Michal Hocko <mhocko@kernel.org>
Date: 2016-09-23 12:10:03
Also in:
lkml
On Fri 23-09-16 12:55:23, Vlastimil Babka wrote:
On 09/23/2016 10:26 AM, Michal Hocko wrote:quoted
quoted
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.
Does anybody depend on that or even use it out there? I strongly suspect this is one of those dark corners people even do not know they exist...
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?
Whatever makes the code easier to understand. Please do not take me wrong I do not want to push back on this too hard I just always love to get rid of an obscure heuristic which even might not matter. And as your testing suggests this might really be the case for !costly orders AFAIU. -- Michal Hocko SUSE Labs -- 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/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>