On 31.01.24 12:16, Ryan Roberts wrote:
On 31/01/2024 11:06, David Hildenbrand wrote:
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?
Nope; running the exact same kernel binary and user space on Altra, I see
sensible numbers;
fork order-0: -1.3%
fork order-9: -7.6%
dontneed order-0: -0.5%
dontneed order-9: 0.1%
munmap order-0: 0.0%
munmap order-9: -67.9%
So I guess some pipelining issue that causes the M2 to stall more?
With one effective added folio_test_large(), it could only be a code
layout problem? Or the compiler does something stupid, but you say that
you run the exact same kernel binary, so that doesn't make sense.
I'm also surprised about the dontneed vs. munmap numbers. Doesn't make
any sense (again, there was this VMA merging problem but it would still
allow for batching within a single VMA that spans exactly one large folio).
What are you using as baseline? Really just mm-unstable vs.
mm-unstable+patches?
Let's see if the new test changes the numbers you measure.
--
Cheers,
David / dhildenb
