Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1445205

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

From Joonsoo Kim <iamjoonsoo.kim@lge.com>
Newsgroups linux.kernel
Subject Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps
Date 2016-07-18 07:00 +0200
Message-ID <rW8OR-1CK-5@gated-at.bofh.it> (permalink)
References (3 earlier) <rSezv-5yn-5@gated-at.bofh.it> <rSu1z-76m-3@gated-at.bofh.it> <rSB35-3r2-75@gated-at.bofh.it> <rUHe1-5dl-7@gated-at.bofh.it> <rUKOC-7Jy-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Jul 14, 2016 at 10:05:00AM +0100, Mel Gorman wrote:
> On Thu, Jul 14, 2016 at 02:23:32PM +0900, Joonsoo Kim wrote:
> > > 
> > > > > > And, I'd like to know why max() is used for classzone_idx rather than
> > > > > > min()? I think that kswapd should balance the lowest zone requested.
> > > > > > 
> > > > > 
> > > > > If there are two allocation requests -- one zone-constraned and the other
> > > > > zone-unconstrained, it does not make sense to have kswapd skip the pages
> > > > > usable for the zone-unconstrained and waste a load of CPU. You could
> > > > 
> > > > I agree that, in this case, it's not good to skip the pages usable
> > > > for the zone-unconstrained request. But, what I am concerned is that
> > > > kswapd stop reclaim prematurely in the view of zone-constrained
> > > > requestor.
> > > 
> > > It doesn't stop reclaiming for the lower zones. It's reclaiming the LRU
> > > for the whole node that may or may not have lower zone pages at the end
> > > of the LRU. If it does, then the allocation request will be satisfied.
> > > If it does not, then kswapd will think the node is balanced and get
> > > rewoken to do a zone-constrained reclaim pass.
> > 
> > If zone-constrained request could go direct reclaim pass, there would
> > be no problem. But, please assume that request is zone-constrained
> > without __GFP_DIRECT_RECLAIM which is common for some device driver
> > implementation.
> 
> Then it's likely GFP_ATOMIC and it'll wake kswapd on each failure. If
> kswapd is containtly awake for highmem requests then we're reclaiming
> everything anyway.  Remember that if kswapd is reclaiming for higher zones,
> it'll still cover the lower zones eventually. There is no guarantee that
> skipping the highmem pages will satisfy the atomic allocations any faster
> but consuming the CPU to skip the pages is a definite cost.

Okay.

> 
> Even worse, skipping highmem pages when a highmem pages are required may
> ake lowmem pressure worse because those pages are freed faster and can
> be consumed by zone-unconstrained requests.

Okay.

> 
> If this really is a problem in practice then we can consider having
> allocation requests that are zone-constrained and !__GFP_DIRECT_RECLAIM
> set a flag and use the min classzone for the wakeup. That flag remains
> set until kswapd takes at least one pass using the lower classzone and
> clears it. The classzone will not be adjusted higher until that flag is

It would work.

> cleared. I don't think we should do it without evidence that it's a real
> problem because kswapd potentially uses useless CPU and the potential for
> higher lowmem pressure.

Hmmm... I think differently. Your patch changes current behaviour
without any evidence. Code simplification cannot compensate
potential stability issue. Before your patch, kswapd try to
balance for minimum classzone so until dis-advantage of this approach
is proved, it's better to keep original logic.

Thanks.

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


Thread

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-07-14 07:20 +0200
  Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Vlastimil Babka <vbabka@suse.cz> - 2016-07-14 10:40 +0200
    Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-07-18 07:10 +0200
      Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Vlastimil Babka <vbabka@suse.cz> - 2016-07-18 09:00 +0200
        Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-07-18 09:30 +0200
  Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Mel Gorman <mgorman@techsingularity.net> - 2016-07-14 11:10 +0200
    Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether  kswapd sleeps Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-07-18 07:00 +0200

csiph-web