[PATCH v2 02/28] vmscan: take at least one pass with shrinkers

Wanpeng Li liwanp at linux.vnet.ibm.com
Thu Apr 11 07:27:30 UTC 2013

On Thu, Apr 11, 2013 at 10:41:14AM +1000, Dave Chinner wrote:
>On Wed, Apr 10, 2013 at 11:03:39PM +0900, JoonSoo Kim wrote:
>> Another one what I found is that they don't account "nr_reclaimed" precisely.
>> There is no code which check whether "current->reclaim_state" exist or not,
>> except prune_inode().
>That's because prune_inode() can free page cache pages when the
>inode mapping is invalidated. Hence it accounts this in addition
>to the slab objects being freed.
>IOWs, if you have a shrinker that frees pages from the page cache,
>you need to do this. Last time I checked, only inode cache reclaim
>caused extra page cache reclaim to occur, so most (all?) other
>shrinkers do not need to do this.

If we should account "nr_reclaimed" against huge zero page? There are 
large number(512) of pages reclaimed which can throttle direct or 
kswapd relcaim to avoid reclaim excess pages. I can do this work if 
you think the idea is needed.

Wanpeng Li 

>It's just another wart that we need to clean up....
>Dave Chinner
>david at fromorbit.com

More information about the Containers mailing list