Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes

From	Johannes Weiner <hannes@cmpxchg.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes
Date	2017-03-07 20:00 +0100
Message-ID	<tisv0-3b1-9@gated-at.bofh.it> (permalink)
References	(2 earlier) <tgKw1-2hO-13@gated-at.bofh.it> <tgQrL-6Ey-3@gated-at.bofh.it> <thPMZ-uB-3@gated-at.bofh.it> <ti3PY-2mY-5@gated-at.bofh.it> <tikxs-66H-17@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tue, Mar 07, 2017 at 11:17:02AM +0100, Michal Hocko wrote:
> On Mon 06-03-17 11:24:10, Johannes Weiner wrote:
> > @@ -3271,7 +3271,8 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
> >  		 * Raise priority if scanning rate is too low or there was no
> >  		 * progress in reclaiming pages
> >  		 */
> > -		if (raise_priority || !sc.nr_reclaimed)
> > +		nr_reclaimed = sc.nr_reclaimed - nr_reclaimed;
> > +		if (raise_priority || !nr_reclaimed)
> >  			sc.priority--;
> >  	} while (sc.priority >= 1);
> >  
> 
> I would rather not play with the sc state here. From a quick look at
> least 
> 	/*
> 	 * Fragmentation may mean that the system cannot be rebalanced for
> 	 * high-order allocations. If twice the allocation size has been
> 	 * reclaimed then recheck watermarks only at order-0 to prevent
> 	 * excessive reclaim. Assume that a process requested a high-order
> 	 * can direct reclaim/compact.
> 	 */
> 	if (sc->order && sc->nr_reclaimed >= compact_gap(sc->order))
> 		sc->order = 0;
> 
> does rely on the value. Wouldn't something like the following be safer?

Well, what behavior is correct, though? This check looks like an
argument *against* resetting sc.nr_reclaimed.

If kswapd is woken up for a higher order, this check sets a reclaim
cutoff beyond which it should give up on the order and balance for 0.

That's on the scope of the kswapd invocation. Applying this threshold
to the outcome of just the preceeding priority seems like a mistake.

Mel? Vlastimil?

Thread

[PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes Johannes Weiner <hannes@cmpxchg.org> - 2017-03-01 09:00 +0100
  Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-03-02 04:30 +0100
  Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes Shakeel Butt <shakeelb@google.com> - 2017-03-03 02:40 +0100
  Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Minchan Kim <minchan@kernel.org> - 2017-03-03 02:50 +0100
    Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Michal Hocko <mhocko@kernel.org> - 2017-03-03 09:10 +0100
      Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Minchan Kim <minchan@kernel.org> - 2017-03-06 02:40 +0100
        Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Johannes Weiner <hannes@cmpxchg.org> - 2017-03-06 17:40 +0100
          Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable nodes "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-03-07 02:10 +0100
          Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Minchan Kim <minchan@kernel.org> - 2017-03-07 08:50 +0100
          Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Michal Hocko <mhocko@kernel.org> - 2017-03-07 11:30 +0100
            Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Johannes Weiner <hannes@cmpxchg.org> - 2017-03-07 20:00 +0100
              Re: [PATCH 1/9] mm: fix 100% CPU kswapd busyloop on unreclaimable  nodes Mel Gorman <mgorman@suse.de> - 2017-03-09 15:40 +0100

csiph-web