Re: [PATCH v2 3/5] mm: add persistent huge zero folio
From: Pankaj Raghav (Samsung)
Date: Mon Aug 11 2025 - 04:33:55 EST
> This is much nicer and now _super_ simple, I like it.
Thanks to you and David :)
>
> A few nits below but generally:
>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Thanks.
>
> > ---
> > include/linux/huge_mm.h | 16 ++++++++++++++++
> > mm/Kconfig | 16 ++++++++++++++++
> > mm/huge_memory.c | 40 ++++++++++++++++++++++++++++++----------
> > 3 files changed, 62 insertions(+), 10 deletions(-)
> >
> > static inline int split_folio_to_list_to_order(struct folio *folio,
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index e443fe8cd6cf..fbe86ef97fd0 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -823,6 +823,22 @@ config ARCH_WANT_GENERAL_HUGETLB
> > config ARCH_WANTS_THP_SWAP
> > def_bool n
> >
> > +config PERSISTENT_HUGE_ZERO_FOLIO
> > + bool "Allocate a PMD sized folio for zeroing"
> > + depends on TRANSPARENT_HUGEPAGE
>
> I feel like we really need to sort out what is/isn't predicated on THP... it
> seems like THP is sort of short hand for 'any large folio stuff' but not
> always...
>
> But this is a more general point :)
I already brought this topic once during THP cabal. I am thinking of
submitting a talk about this topic for LPC Memory Management MC.
>
> > + help
> > + Enable this option to reduce the runtime refcounting overhead
> > + of the huge zero folio and expand the places in the kernel
> > + that can use huge zero folios. This can potentially improve
> > + the performance while performing an I/O.
>
> NIT: I think we can drop 'an', and probably refactor this sentence to something
> like 'For instance, block I/O benefits from access to large folios for zeroing
> memory'.
>
> > +
> > + With this option enabled, the huge zero folio is allocated
> > + once and never freed. One full huge page worth of memory shall
> > + be used.
>
> NIT: huge page worth -> huge page's worth
>
Thanks for the comments. I will make those changes and send a new
version.
--
Pankaj