Re: [RESEND v7 00/29] mm: PMD-level swap entries for anonymous THPs

[Usama Arif]

On 15/09/2026 04:32, Andrew Morton wrote:
> On Mon, 14 Sep 2026 05:27:50 -0700 Usama Arif <usama.arif@xxxxxxxxx> wrote:
> 
>> When reclaim swaps out a PMD-mapped anonymous THP today, the PMD is
>> split into HPAGE_PMD_NR PTE-level swap entries via TTU_SPLIT_HUGE_PMD
>> before unmap.  This series introduces a PMD-level swap entry so the
>> huge mapping can survive the swap round-trip and do_huge_pmd_swap_page()
>> can restore the PMD mapping directly on swap-in, without waiting for
>> khugepaged to collapse the range later.
> 
> Thanks.  I'd describe this as an inevitable step along our thp journey.
> Has to be done sometime.
> 
> I'll await more review, especially of the core parts: pmd swap fault
> handler (#27) and swapout producer (#28).
> 
> And it's a 29-patch performance optimization without any performance
> testing results ;)  Is efficacy testing in the works?

I previously tested an older revision and reran the test this morning
with the current revision. I used vm-scalability's case-swap-w-seq
benchmark [1].

The test configuration was:

- 4 vCPUs and 4 GiB RAM
- 4 pinned workers
- 8 GiB NOCOW raw virtio swap, cache=none,aio=native
- zswap disabled; THP allocation and defrag set to always
- 6 GiB total anonymous working set
- 8 sequential write passes

Four workers repeatedly write the working set, forcing memory to be
swapped out and back in. The results below are the medians of five
interleaved runs per kernel, following one warm-up run:

Metric                           Baseline median   Patched median   Change
Aggregate benchmark throughput   584.3 MiB/s       2,408.9 MiB/s    +312.2% (4.12x)
Elapsed time                     85.43 s           20.72 s          -75.7%
Major faults                     1,814,699         228,466          -87.4%
Swap I/O rate                    1.02 GiB/s        4.10 GiB/s       +303.9%

The results look good as this is a swap-intensive workload.
It primarily demonstrates the reduction in swap-fault and page-table
overhead from preserving PMD mappings.

For long-running workloads, where I believe the series will shine, I expect
benefits from fewer TLB misses, less khugepaged work as well as less kernel churn
due to larger folios, although there aren't a lot of benchmarks to test that.
PMD swap entries also move us closer to eliminating page-table deposits for
anonymous THPs, which would provide memory savings.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/case-swap-w-seq