Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions

From	Michal Hocko <mhocko@kernel.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions
Date	2016-09-23 14:20 +0200
Message-ID	<skxCp-3yR-9@gated-at.bofh.it> (permalink)
References	<sep4R-2HY-3@gated-at.bofh.it> <sjTlD-3mu-3@gated-at.bofh.it> <skdX3-83p-9@gated-at.bofh.it> <sku1P-1iw-3@gated-at.bofh.it> <skwmZ-2zw-11@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Fri 23-09-16 12:55:23, Vlastimil Babka wrote:
> 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.

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions Michal Hocko <mhocko@kernel.org> - 2016-09-21 19:20 +0200
  Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions Vlastimil Babka <vbabka@suse.cz> - 2016-09-22 17:20 +0200
    Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions Michal Hocko <mhocko@kernel.org> - 2016-09-23 10:30 +0200
      Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions Vlastimil Babka <vbabka@suse.cz> - 2016-09-23 13:00 +0200
        Re: [PATCH 0/4] reintroduce compaction feedback for OOM decisions Michal Hocko <mhocko@kernel.org> - 2016-09-23 14:20 +0200

csiph-web