On Mon, Jan 29, 2024 at 12:39 PM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > * Lokesh Gidra <lokeshgidra@xxxxxxxxxx> [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/20240126182647.2748949-1-lokeshgidra@xxxxxxxxxx/ > > > > 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 > > > >
