Re: [RFC PATCH v5] mm: retry page faults once under the per-VMA lock

[Barry Song]

On Mon, Aug 17, 2026 at 11:02 AM Hongru Zhang <zhanghongru06@xxxxxxxxx> wrote:
>
> On Sat, Aug 15, 2026 at 2:51 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, 14 Aug 2026 16:53:00 +0800 Hongru Zhang <zhanghongru06@xxxxxxxxx> wrote:
> >
> > > From: Hongru Zhang <zhanghongru@xxxxxxxxxx>
> > >
> > > The per-VMA lock fault path falls back to mmap_lock on VM_FAULT_RETRY.
> > > When mmap_lock is write-contended, the fallback can reduce page-fault
> > > throughput.
> > >
> > > Add a single retry under the per-VMA lock in the arch fault handler
> > > instead of adding a new VM_FAULT_* flag.
> > >
> > > ...
> > >
> > > Swap Throughput (higher is better):
> > > +--------------+-------------+---------------------------+
> > > | mmap writers |   Vanilla   |          Patched          |
> > > +--------------+-------------+---------------------------+
> > > |      0       | 17303.09 /s | 17899.48 /s       (+3.4%) |
> > > +--------------+-------------+---------------------------+
> > > |      4       | 12596.23 /s | 16095.20 /s      (+27.8%) |
> > > +--------------+-------------+---------------------------+
> > > |      8       |     0.58 /s | 15420.57 /s (+2658619.0%) |
> > > +--------------+-------------+---------------------------+
> >
> > Well.
> >
> > > With increasing mmap_lock write pressure, Vanilla degrades sharply and
> > > drops to near zero at eight writers. Patched kernel holds up much better.
> >
> > Thanks for working on this.
> >
> > Are you able to help us understand how much effect this change will
> > have upon any real-world workloads?
>
> Thanks for raising this.
>
> I'll run some real-world workload tests and follow up with the results.

I guess you just mean double-checking the data with the latest code.

Note that this is a real issue observed with a real workload. In an
earlier version, we had the following data from Douyin (the Chinese
version of TikTok). Oven’s data from the earlier version is shown below
[1].

"The dramatically reduced mmap_lock contention leads to a
significant improvement in Douyin performance.

Douyin (the Chinese version of TikTok) warm start on a smartphone with
8GB RAM."

== mmap_lock Acquisitions And Wait Time ==

Metric                    Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
Read Lock Count           20,010          5,719          -71.42%
Read Total Wait (us)      10,695,877     408,436        -96.18%
Read Avg Wait (us)        534.00         71.00           -86.70%
Write Lock Count          838             909            +8.47%
Write Total Wait (us)     501,293        97,633          -80.52%
Write Avg Wait (us)       598.00         107.00          -82.11%


== Read Lock Waiting Time Distribution of mmap_lock ==

Range (us)                 Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
[0, 1)                     9,927           4,286          -56.82%
[1, 10)                    9,179           1,327          -85.54%
[10, 100)                  191             88             -53.93%
[100, 1000)                57              6              -89.47%
[1000, 10000)              328             9              -97.26%
[10000, 100000)            328             6              -98.17%
[100000, 1000000)          0               0              N/A
[1000000, +)               0               0              N/A

== Write Lock Waiting Time Distribution of mmap_lock ==

Range (us)                 Before (Avg)    After (Avg)    Change
------------------------------------------------------------------------
[0, 1)                     250             300            +20.00%
[1, 10)                    483             556            +15.11%
[10, 100)                  52              41             -21.15%
[100, 1000)                12              5              -58.33%
[1000, 10000)              22              4              -81.82%
[10000, 100000)            16              1              -93.75%
[100000, 1000000)          0               0              N/A
[1000000, +)               0               0              N/A


You also have the Pixel 6 data showing that `mmap_lock` is a major
source of frame drops.
I guess you may just want to re-test those Android cases with the latest
code from this version.

[1] https://lore.kernel.org/all/20260430040427.4672-1-baohua@xxxxxxxxxx/

Thanks
Barry