On Wed, 28 May 2014, Konstantin Khlebnikov wrote:

On Wed, May 28, 2014 at 1:17 AM, Hugh Dickins [off-list ref] wrote:

quoted

On Tue, 27 May 2014, Dave Chinner wrote:

quoted

On Mon, May 26, 2014 at 02:44:29PM -0700, Hugh Dickins wrote:

quoted

[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@google.com>

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>