linux-kernel - Re: [PATCH v8 0/7] mm: folio_zero

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h5v676f4.fsf@oracle.com>
Date: Thu, 06 Nov 2025 21:33:51 -0800
From: Ankur Arora <ankur.a.arora@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
        david@...hat.com, 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


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.


Thanks

--
ankur