On Fri, 2013-08-30 at 11:40 +1000, Dave Chinner wrote: > > The new shrinker infrastructure has a ->count_objects() callout to > specifically return the number of objects in the cache. > shrink_slab_node() can check that return value against the "minimum > call count" and determine whether it needs to call ->scan_objects() > at all. > > Actually, the shrinker already behaves like this with the batch_size > variable - the shrinker has to be asking for more items to be > scanned than the batch size. That means the problem is that counting > callouts are causing the problem, not the scanning callouts. > > With the new code in the mmotm tree, for counting purposes we > probably don't need to grab a passive superblock reference at all - > the superblock and LRUs are guaranteed to be valid if the shrinker > is currently running, but we don't really care if the superblock is > being shutdown and the values that come back are invalid because the > ->scan_objects() callout will fail to grab the superblock to do > anything with the calculated values. If that's the case, then we should remove grab_super_passive from the super_cache_count code. That should remove the bottleneck in reclamation. Thanks for your detailed explanation. Tim Signed-off-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> --- diff --git a/fs/super.c b/fs/super.c index 73d0952..4df1fab 100644 --- a/fs/super.c +++ b/fs/super.c @@ -112,9 +112,6 @@ static unsigned long super_cache_count(struct shrinker *shrink, sb = container_of(shrink, struct super_block, s_shrink); - if (!grab_super_passive(sb)) - return 0; - if (sb->s_op && sb->s_op->nr_cached_objects) total_objects = sb->s_op->nr_cached_objects(sb, sc->nid); -- 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
