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

[Usama Arif]

On 16/09/2026 01:00, Andrew Morton wrote:
> On Tue, 15 Sep 2026 15:09:16 +0100 Usama Arif <usama.arif@xxxxxxxxx> wrote:
> 
>>
>> 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.
>>
> 
> Thanks.  Wow.
> 
> This doesn't look totally real-world but it's close enough to indicate
> that real people doing real things will see nice benefits from this
> change.  As expected - leaving post-swapin thp reassembly to khugepaged
> was so lame.
> 

Yes, exactly! I initially left it out because case-swap-w-seq is a
swap-intensive synthetic workload and might not be a representative
application benchmark. Completely agree that lower reliance on
khugepaged will be a much bigger impact of this series. Unfortunately
I cant find any benchmark that would capture the affect of that.

> Please add the above info to the [0/N] and maintain it.
> 

Will do!

> (I'm itching to get this moving ahead, but we do need eyes on those
> core bits).

Thanks for helping move this forward!