Thread (5 messages) 5 messages, 3 authors, 2016-06-29

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

From: Vladimir Davydov <hidden>
Date: 2016-06-28 16:49:00
Also in: lkml

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:
quoted
On Mon, Jun 27, 2016 at 07:02:15PM +0800, Chen Feng wrote:
quoted
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.
OKi 1/4 ? 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.
quoted
quoted
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.

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help