Messages in this thread | | | Subject | Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions | From | Vlastimil Babka <> | Date | Fri, 23 Sep 2016 12:55:23 +0200 |
| |
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?
| |