[v2,0/3] per-vma locks in userfaultfd

Message

Lokesh Gidra Jan. 29, 2024, 7:35 p.m. UTC

Performing userfaultfd operations (like copy/move etc.) in critical
section of mmap_lock (read-mode) causes significant contention on the
lock when operations requiring the lock in write-mode are taking place
concurrently. We can use per-vma locks instead to significantly reduce
the contention issue.

Changes since v1 [1]:
- rebase patches on 'mm-unstable' branch

[1] https://lore.kernel.org/all/[e-mail]/

Lokesh Gidra (3):
  userfaultfd: move userfaultfd_ctx struct to header file
  userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx
  userfaultfd: use per-vma locks in userfaultfd operations

 fs/userfaultfd.c              |  86 ++++---------
 include/linux/userfaultfd_k.h |  75 ++++++++---
 mm/userfaultfd.c              | 229 ++++++++++++++++++++++------------
 3 files changed, 229 insertions(+), 161 deletions(-)

Comments

Liam R. Howlett Jan. 29, 2024, 8:39 p.m. UTC | #1

* Lokesh Gidra <[e-mail]> [240129 14:35]:
> Performing userfaultfd operations (like copy/move etc.) in critical
> section of mmap_lock (read-mode) causes significant contention on the
> lock when operations requiring the lock in write-mode are taking place
> concurrently. We can use per-vma locks instead to significantly reduce
> the contention issue.

Is this really an issue?  I'm surprised so much userfaultfd work is
happening to create contention.  Can you share some numbers and how your
patch set changes the performance?

> 
> Changes since v1 [1]:
> - rebase patches on 'mm-unstable' branch
> 
> [1] https://lore.kernel.org/all/[e-mail]/
> 
> Lokesh Gidra (3):
>   userfaultfd: move userfaultfd_ctx struct to header file
>   userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx
>   userfaultfd: use per-vma locks in userfaultfd operations
> 
>  fs/userfaultfd.c              |  86 ++++---------
>  include/linux/userfaultfd_k.h |  75 ++++++++---
>  mm/userfaultfd.c              | 229 ++++++++++++++++++++++------------
>  3 files changed, 229 insertions(+), 161 deletions(-)
> 
> -- 
> 2.43.0.429.g432eaa2c6b-goog
> 
>

Lokesh Gidra Jan. 29, 2024, 9:58 p.m. UTC | #2

On Mon, Jan 29, 2024 at 12:39 PM Liam R. Howlett
<[e-mail]> wrote:
>
> * Lokesh Gidra <[e-mail]> [240129 14:35]:
> > Performing userfaultfd operations (like copy/move etc.) in critical
> > section of mmap_lock (read-mode) causes significant contention on the
> > lock when operations requiring the lock in write-mode are taking place
> > concurrently. We can use per-vma locks instead to significantly reduce
> > the contention issue.
>
> Is this really an issue?  I'm surprised so much userfaultfd work is
> happening to create contention.  Can you share some numbers and how your
> patch set changes the performance?
>

In Android we are using userfaultfd for Android Runtime's GC
compaction. mmap-lock (write-mode) operations like mmap/munmap/mlock
happening simultaneously elsewhere in the process caused significant
contention. Of course, this doesn't happen during every compaction,
but whenever it does it leads to a jittery experience for the user.
During one such reproducible scenario, we observed the following
improvements with this patch-set:

- Wall clock time of compaction phase came down from ~3s to less than 500ms
- Uninterruptible sleep time (across all threads in the process) was
~10ms (none was in mmap_lock) during compaction, instead of >20s

I will add these numbers in the cover letter in the next version of
this patchset.

> >
> > Changes since v1 [1]:
> > - rebase patches on 'mm-unstable' branch
> >
> > [1] https://lore.kernel.org/all/[e-mail]/
> >
> > Lokesh Gidra (3):
> >   userfaultfd: move userfaultfd_ctx struct to header file
> >   userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx
> >   userfaultfd: use per-vma locks in userfaultfd operations
> >
> >  fs/userfaultfd.c              |  86 ++++---------
> >  include/linux/userfaultfd_k.h |  75 ++++++++---
> >  mm/userfaultfd.c              | 229 ++++++++++++++++++++++------------
> >  3 files changed, 229 insertions(+), 161 deletions(-)
> >
> > --
> > 2.43.0.429.g432eaa2c6b-goog
> >
> >