Re: [PATCH] mm, vmscan: set shrinker to the left page count

[Vladimir Davydov]

On Tue, Jun 28, 2016 at 06:37:24PM +0800, Chen Feng wrote:
> Thanks for you reply.
> 
> On 2016/6/28 0:57, Vladimir Davydov wrote:
> > On Mon, Jun 27, 2016 at 07:02:15PM +0800, Chen Feng wrote:
> >> In my platform, there can be cache a lot of memory in
> >> ion page pool. When shrink memory the nr_to_scan to ion
> >> is always to little.
> >> to_scan: 395  ion_pool_cached: 27305
> > 
> > That's OK. We want to shrink slabs gradually, not all at once.
> > 
> 
> OKï But my question there are a lot of memory waiting for free.
> But the to_scan is too little.

Small value of 'total_scan' in comparison to 'freeable' (in shrink_slab)
means that memory pressure is not really high and so there's no need to
scan all cached objects yet.

> 
> So, the lowmemorykill may kill the wrong process.
> >>
> >> Currently, the shrinker nr_deferred is set to total_scan.
> >> But it's not the real left of the shrinker.
> > 
> > And it shouldn't. The idea behind nr_deferred is following. A shrinker
> > may return SHRINK_STOP if the current allocation context doesn't allow
> > to reclaim its objects (e.g. reclaiming inodes under GFP_NOFS is
> > deadlock prone). In this case we can't call the shrinker right now, but
> > if we just forget about the batch we are supposed to reclaim at the
> > current iteration, we can wind up having too many of these objects so
> > that they start to exert unfairly high pressure on user memory. So we
> > add the amount that we wanted to scan but couldn't to nr_deferred, so
> > that we can catch up when we get to shrink_slab() with a proper context.
> > 
> I am confused with your comments. If the shrinker return STOP this time.
> It also can return STOP next time.

There's always kswapd running in background which calls reclaim with
GFP_KERNEL. So even if a process issues a lot of successive GFP_NOFS,
which makes fs shrinkers abort scan, their objects will still be scanned
and reclaimed by kswapd.