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

Groups > linux.kernel > #1445209

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

Show all headers | View raw

On Thu, Jul 14, 2016 at 10:32:09AM +0200, Vlastimil Babka wrote:
> On 07/14/2016 07:23 AM, Joonsoo Kim wrote:
> >On Fri, Jul 08, 2016 at 11:11:47AM +0100, Mel Gorman wrote:
> >>On Fri, Jul 08, 2016 at 11:44:47AM +0900, Joonsoo Kim wrote:
> >>
> >>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. And, please assume one more thing that this request
> >always comes with zone-unconstrained allocation request. In this case,
> >your max() logic will set kswapd_classzone_idx to highest zone index
> >and re-worken kswapd would not balance for low zone again. In the end,
> >zone-constrained allocation request without __GFP_DIRECT_RECLAIM could
> >fail.
> 
> I don't think there's a problem in the scenario? Kswapd will keep
> being woken up and reclaim from the node lru. It will hit and free
> any low zone pages that are on the lru, even though it doesn't
> "balance for low zone". Eventually it will either satisfy the
> constrained allocation by reclaiming those low-zone pages during the
> repeated wakeups, or the low-zone wakeups will stop coming together
> with higher-zone wakeups and then it will reclaim the low-zone pages
> in a single low-zone wakeup. If the zone-constrained request is not

Yes, probability of this would be low.

> allowed to fail, then it will just keep waking up kswapd and waiting
> for the progress. If it's allowed to fail (i.e. not __GFP_NOFAIL),
> but not allowed to direct reclaim, it goes "goto nopage" rather
> quickly in __alloc_pages_slowpath(), without any waiting for
> kswapd's progress, so there's not really much difference whether the
> kswapd wakeup picked up a low classzone or not. Note the

Hmm... Even if allocation could fail, we should do our best to prevent
failure. Relying on luck isn't good idea to me.

Thanks.

> __GFP_NOFAIL but ~__GFP_DIRECT_RECLAIM is a WARN_ON_ONCE() scenario,
> so definitely not common...
> 
> >Thanks.
> >
> 
> --
> 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>

Back to linux.kernel | Previous | Next — Previous in thread | Next 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