> 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
