[LSM/MM/BPF TOPIC] Do not hold mmap_lock following folio_lock failure in page faults

[LSM/MM/BPF TOPIC] Do not hold mmap_lock following folio_lock failure in page faults

[Barry Song]

Currently, page faults use per-VMA locks whenever possible.
However, when a page fault encounters an I/O read (e.g., in
filemap_fault() or do_swap_page()), the handler releases the
per-VMA lock and requests a retry after failing to acquire
folio_lock. On the retry, the fault handler always acquires
the mmap_lock in read mode unconditionally.

This can occur frequently and may sometimes cause UI jank due
to mmap_lock contention. A proposal suggests using the
per-VMA lock in the page fault retry path instead of taking
mmap_lock [1]. Oven reported that this can significantly
improve performance by reducing mmap_lock wait time [2].

Matthew appears to suggest removing the page fault retry
entirely and instead waiting for I/O while holding the
per-VMA lock, noting that folios under I/O read may be
reclaimed by the LRU under severe memory pressure and
with thousands of threads. As a result, folios might be
reallocated, causing the page fault to repeatedly re-enter [3].
However, holding the per-VMA lock during I/O wait raises
some concerns: writers could experience long delays.

On the other hand, retrying with the per-VMA lock may reduce
mmap_lock contention, potentially shortening page fault retry
time and giving the LRU fewer opportunities to reclaim folios
waiting for I/O. By the time of the LSF/MM/BPF discussion, I
may have already created similar cases and collected
additional data.

Another potential optimization is to remove the page fault retry
without risking long I/O waits blocking writers. This occurs when
folio_lock fails but the folio is already up-to-date. In this case,
a parallel page fault may simply wait for the simultaneous PF to
complete the PTE mapping.

I would appreciate feedback from LSF/MM/BPF on approaches
to eliminate mmap_lock acquisition in page faults triggered
by folio_lock failure, for both I/O wait and PTE-mapping
wait cases, for mainline inclusion.

[1] https://lore.kernel.org/linux-mm/20251127011438.6918-1-21cnbao@gmail.com/
[2] https://lore.kernel.org/linux-mm/cccf352a-1a68-430d-83fa-a14bb5e37464@oppo.com/
[3] https://lore.kernel.org/linux-mm/aSip2mWX13sqPW_l@casper.infradead.org/

Thanks
Barry

Re: [LSM/MM/BPF TOPIC] Do not hold mmap_lock following folio_lock failure in page faults

[Suren Baghdasaryan]

On Fri, Feb 20, 2026 at 2:13 PM Barry Song <21cnbao@gmail.com> wrote:
>
> Currently, page faults use per-VMA locks whenever possible.
> However, when a page fault encounters an I/O read (e.g., in
> filemap_fault() or do_swap_page()), the handler releases the
> per-VMA lock and requests a retry after failing to acquire
> folio_lock. On the retry, the fault handler always acquires
> the mmap_lock in read mode unconditionally.
>
> This can occur frequently and may sometimes cause UI jank due
> to mmap_lock contention. A proposal suggests using the
> per-VMA lock in the page fault retry path instead of taking
> mmap_lock [1]. Oven reported that this can significantly
> improve performance by reducing mmap_lock wait time [2].
>
> Matthew appears to suggest removing the page fault retry
> entirely and instead waiting for I/O while holding the
> per-VMA lock, noting that folios under I/O read may be
> reclaimed by the LRU under severe memory pressure and
> with thousands of threads. As a result, folios might be
> reallocated, causing the page fault to repeatedly re-enter [3].
> However, holding the per-VMA lock during I/O wait raises
> some concerns: writers could experience long delays.
>
> On the other hand, retrying with the per-VMA lock may reduce
> mmap_lock contention, potentially shortening page fault retry
> time and giving the LRU fewer opportunities to reclaim folios
> waiting for I/O. By the time of the LSF/MM/BPF discussion, I
> may have already created similar cases and collected
> additional data.
>
> Another potential optimization is to remove the page fault retry
> without risking long I/O waits blocking writers. This occurs when
> folio_lock fails but the folio is already up-to-date. In this case,
> a parallel page fault may simply wait for the simultaneous PF to
> complete the PTE mapping.
>
> I would appreciate feedback from LSF/MM/BPF on approaches
> to eliminate mmap_lock acquisition in page faults triggered
> by folio_lock failure, for both I/O wait and PTE-mapping
> wait cases, for mainline inclusion.

Would love to participate in this discussion. Hope Barry can attend in
person this time :)

>
> [1] https://lore.kernel.org/linux-mm/20251127011438.6918-1-21cnbao@gmail.com/
> [2] https://lore.kernel.org/linux-mm/cccf352a-1a68-430d-83fa-a14bb5e37464@oppo.com/
> [3] https://lore.kernel.org/linux-mm/aSip2mWX13sqPW_l@casper.infradead.org/
>
> Thanks
> Barry

Re: [LSM/MM/BPF TOPIC] Do not hold mmap_lock following folio_lock failure in page faults

[Liam R. Howlett]

* Suren Baghdasaryan <surenb@google.com> [260224 12:14]:
> On Fri, Feb 20, 2026 at 2:13 PM Barry Song <21cnbao@gmail.com> wrote:
> >
> > Currently, page faults use per-VMA locks whenever possible.
> > However, when a page fault encounters an I/O read (e.g., in
> > filemap_fault() or do_swap_page()), the handler releases the
> > per-VMA lock and requests a retry after failing to acquire
> > folio_lock. On the retry, the fault handler always acquires
> > the mmap_lock in read mode unconditionally.
> >
> > This can occur frequently and may sometimes cause UI jank due
> > to mmap_lock contention. A proposal suggests using the
> > per-VMA lock in the page fault retry path instead of taking
> > mmap_lock [1]. Oven reported that this can significantly
> > improve performance by reducing mmap_lock wait time [2].
> >
> > Matthew appears to suggest removing the page fault retry
> > entirely and instead waiting for I/O while holding the
> > per-VMA lock, noting that folios under I/O read may be
> > reclaimed by the LRU under severe memory pressure and
> > with thousands of threads. As a result, folios might be
> > reallocated, causing the page fault to repeatedly re-enter [3].
> > However, holding the per-VMA lock during I/O wait raises
> > some concerns: writers could experience long delays.
> >
> > On the other hand, retrying with the per-VMA lock may reduce
> > mmap_lock contention, potentially shortening page fault retry
> > time and giving the LRU fewer opportunities to reclaim folios
> > waiting for I/O. By the time of the LSF/MM/BPF discussion, I
> > may have already created similar cases and collected
> > additional data.
> >
> > Another potential optimization is to remove the page fault retry
> > without risking long I/O waits blocking writers. This occurs when
> > folio_lock fails but the folio is already up-to-date. In this case,
> > a parallel page fault may simply wait for the simultaneous PF to
> > complete the PTE mapping.
> >
> > I would appreciate feedback from LSF/MM/BPF on approaches
> > to eliminate mmap_lock acquisition in page faults triggered
> > by folio_lock failure, for both I/O wait and PTE-mapping
> > wait cases, for mainline inclusion.
> 
> Would love to participate in this discussion. Hope Barry can attend in
> person this time :)

I would also like to participate in an in-person discussion about this.

...

> 
> >
> > [1] https://lore.kernel.org/linux-mm/20251127011438.6918-1-21cnbao@gmail.com/
> > [2] https://lore.kernel.org/linux-mm/cccf352a-1a68-430d-83fa-a14bb5e37464@oppo.com/
> > [3] https://lore.kernel.org/linux-mm/aSip2mWX13sqPW_l@casper.infradead.org/

...

Thanks,
Liam

Re: [LSM/MM/BPF TOPIC] Do not hold mmap_lock following folio_lock failure in page faults

[Barry Song]

On Wed, Feb 25, 2026 at 5:21 AM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * Suren Baghdasaryan <surenb@google.com> [260224 12:14]:
[...]
> > >
> > > I would appreciate feedback from LSF/MM/BPF on approaches
> > > to eliminate mmap_lock acquisition in page faults triggered
> > > by folio_lock failure, for both I/O wait and PTE-mapping
> > > wait cases, for mainline inclusion.
> >
> > Would love to participate in this discussion. Hope Barry can attend in
> > person this time :)
>
> I would also like to participate in an in-person discussion about this.
>
> ...

Thank you very much to Suren and Liam for showing interest in this topic.
I’ll do my best to attend in person if the opportunity arises, though it’s
not yet 100% certain.

Thanks
Barry