[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1a0e9b3-dae2-418f-bd63-50e65f471728@redhat.com>
Date: Wed, 31 Jan 2024 12:06:59 +0100
From: David Hildenbrand <david@...hat.com>
To: Ryan Roberts <ryan.roberts@....com>, linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>, Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Dinh Nguyen <dinguyen@...nel.org>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
"Aneesh Kumar K.V" <aneesh.kumar@...nel.org>,
"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
<palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>, "David S. Miller"
<davem@...emloft.net>, linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH v3 00/15] mm/memory: optimize fork() with PTE-mapped THP
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
Powered by blists - more mailing lists