Re: [RFC PATCH v5] mm: retry page faults once under the per-VMA lock
Barry Song <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <CAGsJ_4xt+OfZP40WVnJK9wnPwOP6tFf7QEaXyB4ZozsWuWRk8Q@mail.gmail.com> |
On Mon, Aug 17, 2026 at 11:02 AM Hongru Zhang <[email protected]> wrote: > > On Sat, Aug 15, 2026 at 2:51 AM Andrew Morton <[email protected]> wrote: > > > > On Fri, 14 Aug 2026 16:53:00 +0800 Hongru Zhang <[email protected]> wrote: > > > > > From: Hongru Zhang <[email protected]> > > > > > > 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/[email protected]/ Thanks Barry