forked from Minki/linux
e76eebee70
There is a performance problem: when all sbi->fs_lock are holded, then all the following threads may get the same next_lock value from sbi->next_lock_num in function mutex_lock_op, and wait for the same lock(fs_lock[next_lock]), it may cause performance reduce. So we move the sbi->next_lock_num++ before getting lock, this will average the following threads if all sbi->fs_lock are holded. v1-->v2: Drop the needless spin_lock as Jaegeuk suggested. Suggested-by: Jaegeuk Kim <jaegeuk.kim@samsung.com> Signed-off-by: Yu Chao <chao2.yu@samsung.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com> |
||
|---|---|---|
| .. | ||
| acl.c | ||
| acl.h | ||
| checkpoint.c | ||
| data.c | ||
| debug.c | ||
| dir.c | ||
| f2fs.h | ||
| file.c | ||
| gc.c | ||
| gc.h | ||
| hash.c | ||
| inode.c | ||
| Kconfig | ||
| Makefile | ||
| namei.c | ||
| node.c | ||
| node.h | ||
| recovery.c | ||
| segment.c | ||
| segment.h | ||
| super.c | ||
| xattr.c | ||
| xattr.h | ||