On Tue, 27 May 2014, Dave Chinner wrote: > On Mon, May 26, 2014 at 02:44:29PM -0700, Hugh Dickins wrote: > > > > [PATCH 4/3] fs/superblock: Avoid counting without __GFP_FS > > > > Don't waste time counting objects in super_cache_count() if no __GFP_FS: > > super_cache_scan() would only back out with SHRINK_STOP in that case. > > > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > > While you might think that's a good thing, it's not. The act of > shrinking is kept separate from the accounting of how much shrinking > needs to take place. The amount of work the shrinker can't do due > to the reclaim context is deferred until the shrinker is called in a > context where it can do work (eg. kswapd) > > Hence not accounting for work that can't be done immediately will > adversely impact the balance of the system under memory intensive > filesystem workloads. In these worklaods, almost all allocations are > done in the GFP_NOFS or GFP_NOIO contexts so not deferring the work > will will effectively stop superblock cache reclaim entirely.... Thanks for filling me in on that. At first I misunderstood you, and went off looking in the wrong direction. Now I see what you're referring to: the quantity that shrink_slab_node() accumulates in and withdraws from shrinker->nr_deferred[nid]. Right: forget my super_cache_count() __GFP_FS patch! Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html