diff options
author | Konstantin Khlebnikov <khlebnikov@yandex-team.ru> | 2015-02-19 20:19:35 +0300 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2015-02-22 11:38:42 -0500 |
commit | eb6ef3df4faa5424cf2a24b4e4f3eeceb1482a8e (patch) | |
tree | 760db5df872be2122597841c33479c41cf2d7194 /drivers/thunderbolt | |
parent | 54f2a2f42759b11ada761013a12f0e743702219a (diff) |
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>
Diffstat (limited to 'drivers/thunderbolt')
0 files changed, 0 insertions, 0 deletions