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. Regards, Wanpeng Li >It's just another wart that we need to clean up.... > >Cheers, > >Dave. >-- >Dave Chinner >david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>