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. -- 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
