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

[David Hildenbrand (Red Hat)]

On 07.11.25 06:33, Ankur Arora wrote:
> Ankur Arora <ankur.a.arora@xxxxxxxxxx> writes:
>
> > [ My earlier reply to this ate up some of the headers and broke out of
> > the thread. Resending. ]
> >
> > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
> >
> > > On Mon, 27 Oct 2025 13:21:02 -0700 Ankur Arora <ankur.a.arora@xxxxxxxxxx> 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@xxxxxxxxxx/#r
> > [b] https://lore.kernel.org/lkml/20220606202109.1306034-1-ankur.a.arora@xxxxxxxxxx/
> >
> > > > 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