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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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