ping? Andrew any chance of getting this in -next? On Thu, 2014-05-22 at 20:33 -0700, Davidlohr Bueso wrote: > This patchset extends the work started by Ingo Molnar in late 2012, > optimizing the anon-vma mutex lock, converting it from a exclusive mutex > to a rwsem, and sharing the lock for read-only paths when walking the > the vma-interval tree. More specifically commits 5a505085 and 4fc3f1d6. > > The i_mmap_mutex has similar responsibilities with the anon-vma, protecting > file backed pages. Therefore we can use similar locking techniques: covert > the mutex to a rwsem and share the lock when possible. > > With the new optimistic spinning property we have in rwsems, we no longer > take a hit in performance when using this lock, and we can therefore > safely do the conversion. Tests show no throughput regressions in aim7 or > pgbench runs, and we can see gains from sharing the lock, in disk workloads > ~+15% for over 1000 users on a 8-socket Westmere system. > > This patchset applies on linux-next-20140522. > > Thanks! > > Davidlohr Bueso (5): > mm,fs: introduce helpers around i_mmap_mutex > mm: use new helper functions around the i_mmap_mutex > mm: convert i_mmap_mutex to rwsem > mm/rmap: share the i_mmap_rwsem > mm: rename leftover i_mmap_mutex > > fs/hugetlbfs/inode.c | 14 +++++++------- > fs/inode.c | 2 +- > include/linux/fs.h | 23 ++++++++++++++++++++++- > include/linux/mmu_notifier.h | 2 +- > kernel/events/uprobes.c | 6 +++--- > kernel/fork.c | 4 ++-- > mm/filemap.c | 10 +++++----- > mm/filemap_xip.c | 4 ++-- > mm/hugetlb.c | 22 +++++++++++----------- > mm/memory-failure.c | 4 ++-- > mm/memory.c | 8 ++++---- > mm/mmap.c | 22 +++++++++++----------- > mm/mremap.c | 6 +++--- > mm/nommu.c | 14 +++++++------- > mm/rmap.c | 10 +++++----- > 15 files changed, 86 insertions(+), 65 deletions(-) > -- 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
