summaryrefslogtreecommitdiffstats
path: root/mm/mempool.c
diff options
context:
space:
mode:
authorShaohua Li <shaohua.li@intel.com>2010-08-09 17:19:06 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2010-08-09 20:44:58 -0700
commitff36b801624d02a876bb7deded6ab860ea3503f2 (patch)
treea3f44d01de629234d70ad6211b9fd73fd705a76c /mm/mempool.c
parent7e496299d4d2ad8083effed6c5a18313a919edc6 (diff)
downloadlinux-ff36b801624d02a876bb7deded6ab860ea3503f2.tar.gz
linux-ff36b801624d02a876bb7deded6ab860ea3503f2.tar.bz2
linux-ff36b801624d02a876bb7deded6ab860ea3503f2.zip
shmem: reduce pagefault lock contention
I'm running a shmem pagefault test case (see attached file) under a 64 CPU system. Profile shows shmem_inode_info->lock is heavily contented and 100% CPUs time are trying to get the lock. In the pagefault (no swap) case, shmem_getpage gets the lock twice, the last one is avoidable if we prealloc a page so we could reduce one time of locking. This is what below patch does. The result of the test case: 2.6.35-rc3: ~20s 2.6.35-rc3 + patch: ~12s so this is 40% improvement. One might argue if we could have better locking for shmem. But even shmem is lockless, the pagefault will soon have pagecache lock heavily contented because shmem must add new page to pagecache. So before we have better locking for pagecache, improving shmem locking doesn't have too much improvement. I did a similar pagefault test against a ramfs file, the test result is ~10.5s. [akpm@linux-foundation.org: fix comment, clean up code layout, elimintate code duplication] Signed-off-by: Shaohua Li <shaohua.li@intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: "Zhang, Yanmin" <yanmin.zhang@intel.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/mempool.c')
0 files changed, 0 insertions, 0 deletions