Re: [PATCH v3 00/15] mm/memory: optimize fork() with PTE-mapped THP

[David Hildenbrand <david@redhat.com>]

On 31.01.24 11:43, Ryan Roberts wrote:
> On 29/01/2024 12:46, David Hildenbrand wrote:
>> Now that the rmap overhaul[1] is upstream that provides a clean interface
>> for rmap batching, let's implement PTE batching during fork when processing
>> PTE-mapped THPs.
>>
>> This series is partially based on Ryan's previous work[2] to implement
>> cont-pte support on arm64, but its a complete rewrite based on [1] to
>> optimize all architectures independent of any such PTE bits, and to
>> use the new rmap batching functions that simplify the code and prepare
>> for further rmap accounting changes.
>>
>> We collect consecutive PTEs that map consecutive pages of the same large
>> folio, making sure that the other PTE bits are compatible, and (a) adjust
>> the refcount only once per batch, (b) call rmap handling functions only
>> once per batch and (c) perform batch PTE setting/updates.
>>
>> While this series should be beneficial for adding cont-pte support on
>> ARM64[2], it's one of the requirements for maintaining a total mapcount[3]
>> for large folios with minimal added overhead and further changes[4] that
>> build up on top of the total mapcount.
>>
>> Independent of all that, this series results in a speedup during fork with
>> PTE-mapped THP, which is the default with THPs that are smaller than a PMD
>> (for example, 16KiB to 1024KiB mTHPs for anonymous memory[5]).
>>
>> On an Intel Xeon Silver 4210R CPU, fork'ing with 1GiB of PTE-mapped folios
>> of the same size (stddev < 1%) results in the following runtimes
>> for fork() (shorter is better):
>>
>> Folio Size | v6.8-rc1 |      New | Change
>> ------------------------------------------
>>        4KiB | 0.014328 | 0.014035 |   - 2%
>>       16KiB | 0.014263 | 0.01196  |   -16%
>>       32KiB | 0.014334 | 0.01094  |   -24%
>>       64KiB | 0.014046 | 0.010444 |   -26%
>>      128KiB | 0.014011 | 0.010063 |   -28%
>>      256KiB | 0.013993 | 0.009938 |   -29%
>>      512KiB | 0.013983 | 0.00985  |   -30%
>>     1024KiB | 0.013986 | 0.00982  |   -30%
>>     2048KiB | 0.014305 | 0.010076 |   -30%
> 
> Just a heads up that I'm seeing some strange results on Apple M2. Fork for
> order-0 is seemingly costing ~17% more. I'm using GCC 13.2 and was pretty sure I
> didn't see this problem with version 1; although that was on a different
> baseline and I've thrown the numbers away so will rerun and try to debug this.
> 

So far, on my x86 tests (Intel, AMD EPYC), I was not able to observe 
this. fork() for order-0 was consistently effectively unchanged. Do you 
observe that on other ARM systems as well?


> | kernel      |   mean_rel |   std_rel |
> |:------------|-----------:|----------:|
> | mm-unstable |       0.0% |      1.1% |
> | patch 1     |      -2.3% |      1.3% |
> | patch 10    |      -2.9% |      2.7% |
> | patch 11    |      13.5% |      0.5% |
> | patch 12    |      15.2% |      1.2% |
> | patch 13    |      18.2% |      0.7% |
> | patch 14    |      20.5% |      1.0% |
> | patch 15    |      17.1% |      1.6% |
> | patch 15    |      16.7% |      0.8% |
> 
> fork for order-9 is looking good (-20%), and for the zap series, munmap is
> looking good, but dontneed is looking poor for both order-0 and 9. But one thing
> at a time... let's concentrate on fork order-0 first.

munmap and dontneed end up calling the exact same call paths. So a big 
performance difference is rather surprising and might indicate something 
else.

(I think I told you that I was running in some kind of VMA merging 
problem where one would suddenly get with my benchmark 1 VMA per page. 
The new benchmark below works around that, but I am not sure if that was 
fixed in the meantime)

VMA merging can of course explain a big difference in fork and munmap 
vs. dontneed times, especially when comparing different code base where 
that VMA merging behavior was different.

> 
> Note that I'm still using the "old" benchmark code. Could you resend me the link
> to the new code? Although I don't think there should be any effect for order-0
> anyway, if I understood your changes correctly?

This is the combined one (small and large PTEs):

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/pte-mapped-folio-benchmarks.c?inline=false

-- 
Cheers,

David / dhildenb