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@xxxxxxx> > --- > 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. -- 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
