trylock_super(): replacement for grab_super_passive()
authorKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Thu, 19 Feb 2015 17:19:35 +0000 (20:19 +0300)
committerAl Viro <viro@zeniv.linux.org.uk>
Sun, 22 Feb 2015 16:38:42 +0000 (11:38 -0500)
commiteb6ef3df4faa5424cf2a24b4e4f3eeceb1482a8e
tree760db5df872be2122597841c33479c41cf2d7194
parent54f2a2f42759b11ada761013a12f0e743702219a
trylock_super(): replacement for grab_super_passive()

I've noticed significant locking contention in memory reclaimer around
sb_lock inside grab_super_passive(). Grab_super_passive() is called from
two places: in icache/dcache shrinkers (function super_cache_scan) and
from writeback (function __writeback_inodes_wb). Both are required for
progress in memory allocator.

Grab_super_passive() acquires sb_lock to increment sb->s_count and check
sb->s_instances. It seems sb->s_umount locked for read is enough here:
super-block deactivation always runs under sb->s_umount locked for write.
Protecting super-block itself isn't a problem: in super_cache_scan() sb
is protected by shrinker_rwsem: it cannot be freed if its slab shrinkers
are still active. Inside writeback super-block comes from inode from bdi
writeback list under wb->list_lock.

This patch removes locking sb_lock and checks s_instances under s_umount:
generic_shutdown_super() unlinks it under sb->s_umount locked for write.
New variant is called trylock_super() and since it only locks semaphore,
callers must call up_read(&sb->s_umount) instead of drop_super(sb) when
they're done.

Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/fs-writeback.c
fs/internal.h
fs/super.c