Re: [patch 2/2] fs: scale vfsmount_lock

[Nick Piggin <npiggin@suse.de>]

On Tue, Mar 16, 2010 at 11:23:20PM +1100, Nick Piggin wrote:
> fs: scale vfsmount_lock
> 
> Use a brlock for the vfsmount lock. It must be taken for write whenever
> modifying the mount hash or associated fields, and may be taken for read when
> performing mount hash lookups.
> 
> The slowpath will be made significantly slower due to use of brlock. On a 64
> core, 64 socket, 32 node Altix system (so a decent amount of latency to remote
> nodes), a simple umount microbenchmark (mount --bind mnt mnt2 ; umount mnt2
> loop 1000 times), before this patch it took 6.8s, afterwards took 7.1s, for
> about 5% increase in elapsed time.
> 
> Number of atomics should remain the same for fastpath rlock cases, though code
> will be slightly larger due to per-cpu access. Scalability will probably not be
> much improved in common cases yet, due to other locks getting in the way.
> However independent path lookups over mountpoints should be one case where
> scalability is improved.
> 
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
>  fs/dcache.c                |    4 -
>  fs/namei.c                 |   13 +--
>  fs/namespace.c             |  178 ++++++++++++++++++++++++++++-----------------
>  fs/pnode.c                 |   11 ++
>  fs/proc/base.c             |    4 -
>  include/linux/mount.h      |    4 -
>  kernel/audit_tree.c        |    6 -
>  security/tomoyo/realpath.c |    4 -
>  8 files changed, 141 insertions(+), 83 deletions(-)

This diffstat is obviously not refreshed since your vfsmount lock
cleanup, sorry.