On Wed, 28 May 2014, Konstantin Khlebnikov wrote: > On Wed, May 28, 2014 at 1:17 AM, Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > 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]. > > Maybe shrinker could accumulate fraction nr_pages_scanned / lru_pages > instead of exact amount of required work? Count of shrinkable objects > might be calculated later, when shrinker is called from a suitable context > and can actualy do something. Good idea, probably a worthwhile optimization to think through further. (Though experience says that Dave will explain how that can never work.) 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
