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

David Hildenbrand
2024-01-31T11:07:05Z

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