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


Groups > linux.kernel > #1445274

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 09:30 +0200
Message-ID <rWba2-3by-25@gated-at.bofh.it> (permalink)
References (5 earlier) <rSB35-3r2-75@gated-at.bofh.it> <rUHe1-5dl-7@gated-at.bofh.it> <rUKlC-7jX-81@gated-at.bofh.it> <rW8Yx-1VK-9@gated-at.bofh.it> <rWaGZ-2Mp-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Jul 18, 2016 at 08:51:16AM +0200, Vlastimil Babka wrote:
> On 07/18/2016 07:07 AM, Joonsoo Kim wrote:
> >On Thu, Jul 14, 2016 at 10:32:09AM +0200, Vlastimil Babka wrote:
> >>On 07/14/2016 07:23 AM, Joonsoo Kim wrote:
> >>
> >>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.
> 
> But "Doing our best" has to have some sane limits. Allocation, that

Ensuring to do something for the requested zone at least once isn't insane.

> cannot direct reclaim, already relies on luck. And we are not really
> changing this. The allocation will "goto nopage" before kswapd can
> even wake up and start doing something, regardless of classzone_idx
> used.

But, this patch makes things worse. Even if next allocation comes
after kswapd is waking up and doing something, low zone would not be
balanced due to max classzone_idx and allocation could fail. It is
what this patch changes and I worry.

Thanks.

Back to linux.kernel | Previous | NextPrevious 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