On Mon, Sep 28, 2026 at 6:55 AM Matthew Wilcox <[email protected]> wrote: > > On Tue, Sep 22, 2026 at 09:55:23AM +0100, Lorenzo Stoakes (ARM) wrote: > > On Mon, Sep 21, 2026 at 07:57:23PM +0100, Matthew Wilcox wrote: > > > more to say on this in two weeks at Plumbers. > > > > I look forward to it :) > > So while doing my slides, I realised that what we need to avoid doing > is (a) sleeping while holding the mmap_lock (b) returning RETRY while > holding the VMA lock > > And that turns out to be as simple as this patch: > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index dd09c438fa23..94ed2333f8d8 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -723,6 +723,8 @@ enum { > */ > static inline bool fault_flag_allow_retry_first(enum fault_flag flags) > { > + if (flags & FAULT_FLAG_VMA_LOCK) > + return false; > return (flags & FAULT_FLAG_ALLOW_RETRY) && > (!(flags & FAULT_FLAG_TRIED)); > } > > OK, this is a hack. The function is spectacularly badly named, and > needs to be renamed before a patch can go upstream. But this should > fix the contention on mmap_lock.
Thanks for your suggestion. This is exactly what we did in Android Common Kernel before we had Lorenzo's proposal (bypassing `fault_flag_allow_retry_first()`): https://android.googlesource.com/kernel/common/+/1b9b045a586245cc1c29b2747c6586234c7f5bad%5E%21/#F2 At that time, we couldn't modify ACK with a GKI hook that introduced a new flag. All previous versions of this patchset introduced new flags, which would have broken the KMI. So we had to choose between two evils: 1. mmap_lock contention 2. VMA lock contention We chose the lesser evil — no. 2 — and sent the Android hook for merging into ACK. Now that we have Lorenzo's proposal, which doesn't require any new flag, we are adding a new Android hook just to mimic what Lorenzo's proposal already does: https://android-review.googlesource.com/c/kernel/common/+/4307957/3/arch/arm64/mm/fault.c Note that Lorenzo's proposal avoids mmap_lock contention without introducing any new VMA lock contention. It also doesn't require a new flag that would break KMI. So this is clearly the preferred approach. > > Could somebody try it? I've verified it boots and runs some userspace > fine, but I don't have the workload to test the contention. Both Nanzhe and Hongru tested it before and reported the fork issue. Best Regards Barry
