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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Jun 2016 19:48:34 +0300
From:	Vladimir Davydov <vdavydov@...tuozzo.com>
To:	Chen Feng <puck.chen@...ilicon.com>
CC:	<akpm@...ux-foundation.org>, <hannes@...xchg.org>,
	<mhocko@...e.com>, <vbabka@...e.cz>, <mgorman@...hsingularity.net>,
	<riel@...hat.com>, <linux-mm@...ck.org>,
	<linux-kernel@...r.kernel.org>, <labbott@...hat.com>,
	<suzhuangluan@...ilicon.com>, <oliver.fu@...ilicon.com>,
	<puck.chen@...mail.com>, <dan.zhao@...ilicon.com>,
	<saberlily.xia@...ilicon.com>, <xuyiping@...ilicon.com>
Subject: Re: [PATCH] mm, vmscan: set shrinker to the left page count

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.