Re: [PATCH v8 0/7] mm: folio_zero_user: clear contiguous pages

David Hildenbrand (Red Hat)
2025-11-07T08:59:41Z

On 07.11.25 06:33, Ankur Arora wrote:
>
> Ankur Arora <ankur.a.arora@oracle.com> writes:
>
>> [ My earlier reply to this ate up some of the headers and broke out of
>> the thread. Resending. ]
>>
>> Andrew Morton <akpm@linux-foundation.org> writes:
>>
>>> On Mon, 27 Oct 2025 13:21:02 -0700 Ankur Arora <ankur.a.arora@oracle.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