Re: [PATCH 0/5] mm: i_mmap_mutex to rwsem

From: Davidlohr Bueso
Date: Thu May 29 2014 - 22:20:27 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/