| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <52f67ca1-24c6-4081-99e6-0a1d30da1bd6@kernel.org> Date: Fri, 7 Nov 2025 09:59:35 +0100 From: "David Hildenbrand (Red Hat)" <david@...nel.org> To: Ankur Arora <ankur.a.arora@...cle.com>, Andrew Morton <akpm@...ux-foundation.org> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org, bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com, mjguzik@...il.com, luto@...nel.org, peterz@...radead.org, acme@...nel.org, namhyung@...nel.org, tglx@...utronix.de, willy@...radead.org, raghavendra.kt@....com, boris.ostrovsky@...cle.com, konrad.wilk@...cle.com Subject: Re: [PATCH v8 0/7] mm: folio_zero_user: clear contiguous pages On 07.11.25 06:33, Ankur Arora wrote: > > Ankur Arora <ankur.a.arora@...cle.com> writes: > >> [ My earlier reply to this ate up some of the headers and broke out of >> the thread. Resending. ] >> >> Andrew Morton <akpm@...ux-foundation.org> writes: >> >>> On Mon, 27 Oct 2025 13:21:02 -0700 Ankur Arora <ankur.a.arora@...cle.com> wrote: >>> > > [ ... ] > >> >>> It's possible that we're being excessively aggressive with those >>> cond_resched()s. Have you investigating tuning their frequency so we >>> can use larger extent sizes with these preemption models? >> >> >> folio_zero_user() does a small part of that: for 2MB pages the clearing >> is split in three parts with an intervening cond_resched() for each. >> >> This is of course much simpler than the process_huge_page() approach where >> we do a left right dance around the faulting page. >> >> I had implemented a version of process_huge_page() with larger extent >> sizes that narrowed as we got closer to the faulting page in [a] (x86 >> performance was similar to the current series. See [b]). >> >> In hindsight however, that felt too elaborate and probably unnecessary >> on most modern systems where you have reasonably large caches. >> Where it might help, however, is on more cache constrained systems where >> the spatial locality really does matter. >> >> So, my idea was to start with a simple version, get some testing and >> then fill in the gaps instead of starting with something like [a]. >> >> >> [a] https://lore.kernel.org/lkml/20220606203725.1313715-1-ankur.a.arora@oracle.com/#r >> [b] https://lore.kernel.org/lkml/20220606202109.1306034-1-ankur.a.arora@oracle.com/ >> >>>> The anon-w-seq test in the vm-scalability benchmark, however, does show >>>> worse performance with utime increasing by ~9%: >>>> >>>> stime utime >>>> >>>> baseline 1654.63 ( +- 3.84% ) 811.00 ( +- 3.84% ) >>>> +series 1630.32 ( +- 2.73% ) 886.37 ( +- 5.19% ) >>>> >>>> In part this is because anon-w-seq runs with 384 processes zeroing >>>> anonymously mapped memory which they then access sequentially. As >>>> such this is a likely uncommon pattern where the memory bandwidth >>>> is saturated while also being cache limited because we access the >>>> entire region. >>>> >>>> Raghavendra also tested previous version of the series on AMD Genoa [1]. >>> >>> I suggest you paste Raghavendra's results into this [0/N] - it's >>> important material. >> >> Thanks. Will do. >> >>>> >>>> ... >>>> >>>> arch/alpha/include/asm/page.h | 1 - >>>> arch/arc/include/asm/page.h | 2 + >>>> arch/arm/include/asm/page-nommu.h | 1 - >>>> arch/arm64/include/asm/page.h | 1 - >>>> arch/csky/abiv1/inc/abi/page.h | 1 + >>>> arch/csky/abiv2/inc/abi/page.h | 7 --- >>>> arch/hexagon/include/asm/page.h | 1 - >>>> arch/loongarch/include/asm/page.h | 1 - >>>> arch/m68k/include/asm/page_mm.h | 1 + >>>> arch/m68k/include/asm/page_no.h | 1 - >>>> arch/microblaze/include/asm/page.h | 1 - >>>> arch/mips/include/asm/page.h | 1 + >>>> arch/nios2/include/asm/page.h | 1 + >>>> arch/openrisc/include/asm/page.h | 1 - >>>> arch/parisc/include/asm/page.h | 1 - >>>> arch/powerpc/include/asm/page.h | 1 + >>>> arch/riscv/include/asm/page.h | 1 - >>>> arch/s390/include/asm/page.h | 1 - >>>> arch/sparc/include/asm/page_32.h | 2 + >>>> arch/sparc/include/asm/page_64.h | 1 + >>>> arch/um/include/asm/page.h | 1 - >>>> arch/x86/include/asm/page.h | 6 --- >>>> arch/x86/include/asm/page_32.h | 6 +++ >>>> arch/x86/include/asm/page_64.h | 64 ++++++++++++++++++----- >>>> arch/x86/lib/clear_page_64.S | 39 +++----------- >>>> arch/xtensa/include/asm/page.h | 1 - >>>> include/linux/highmem.h | 29 +++++++++++ >>>> include/linux/mm.h | 69 +++++++++++++++++++++++++ >>>> mm/memory.c | 82 ++++++++++++++++++++++-------- >>>> mm/util.c | 13 +++++ >>>> 30 files changed, 247 insertions(+), 91 deletions(-) >>> >>> I guess this is an mm.git thing, with x86 acks (please). >> >> Ack that. >> >>> The documented review activity is rather thin at this time so I'll sit >>> this out for a while. Please ping me next week and we can reassess, >> >> Will do. And, thanks for the quick look! > > Hi Andrew > > So, the comments I have so far are mostly about clarity around the > connection with preempt model and some cleanups on the x86 patches. > > Other than that, my major concern is wider testing (platforms and > workloads) than mine has been. > > Could you take another look at the series and see what else you think > it needs. Sorry for the delay from my side, I took another look at patches and had some smaller comments. -- Cheers David
Powered by blists - more mailing lists