On Wed, Jul 23, 2025 at 11:06:05AM +0200, David Hildenbrand wrote: > On 22.07.25 11:42, Pankaj Raghav (Samsung) wrote: > > From: Pankaj Raghav <p.raghav@xxxxxxxxxxx> > > > > There are many places in the kernel where we need to zeroout larger > > chunks but the maximum segment we can zeroout at a time by ZERO_PAGE > > is limited by PAGE_SIZE. > > > > This is especially annoying in block devices and filesystems where we > > attach multiple ZERO_PAGEs to the bio in different bvecs. With multipage > > bvec support in block layer, it is much more efficient to send out > > larger zero pages as a part of single bvec. > > > > This concern was raised during the review of adding LBS support to > > XFS[1][2]. > > > > Usually huge_zero_folio is allocated on demand, and it will be > > deallocated by the shrinker if there are no users of it left. At moment, > > huge_zero_folio infrastructure refcount is tied to the process lifetime > > that created it. This might not work for bio layer as the completions > > can be async and the process that created the huge_zero_folio might no > > longer be alive. And, one of the main point that came during discussion > > is to have something bigger than zero page as a drop-in replacement. > > > > Add a config option STATIC_HUGE_ZERO_FOLIO that will always allocate > > the huge_zero_folio, and it will never drop the reference. This makes > > using the huge_zero_folio without having to pass any mm struct and does > > not tie the lifetime of the zero folio to anything, making it a drop-in > > replacement for ZERO_PAGE. > > > > If STATIC_PMD_ZERO_PAGE config option is enabled, then > > mm_get_huge_zero_folio() will simply return this page instead of > > dynamically allocating a new PMD page. > > > > This option can waste memory in small systems or systems with 64k base > > page size. So make it an opt-in and also add an option from individual > > architecture so that we don't enable this feature for larger base page > > size systems. > > > > [1] https://lore.kernel.org/linux-xfs/20231027051847.GA7885@xxxxxx/ > > [2] https://lore.kernel.org/linux-xfs/ZitIK5OnR7ZNY0IG@xxxxxxxxxxxxx/ > > > > Co-Developed-by: David Hildenbrand <david@xxxxxxxxxx> > > "Co-developed-by:" > > And must be followed by > > Signed-of-by: David Hildenbrand <david@xxxxxxxxxx> Sounds good. Actually, I didn't want to add your sign-off without your consent. But I will add it to the patch :) > > As mentioned to the cover letter: spaces vs. tabs. > > > Signed-off-by: Pankaj Raghav <p.raghav@xxxxxxxxxxx> > > --- > > arch/x86/Kconfig | 1 + > > include/linux/huge_mm.h | 16 ++++++++++++++++ > > mm/Kconfig | 12 ++++++++++++ > > mm/huge_memory.c | 28 ++++++++++++++++++++++++++++ > > 4 files changed, 57 insertions(+) > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 0ce86e14ab5e..8e2aa1887309 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -153,6 +153,7 @@ config X86 > > select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP if X86_64 > > select ARCH_WANT_HUGETLB_VMEMMAP_PREINIT if X86_64 > > select ARCH_WANTS_THP_SWAP if X86_64 > > + select ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO if X86_64 > > select ARCH_HAS_PARANOID_L1D_FLUSH > > select ARCH_WANT_IRQS_OFF_ACTIVATE_MM > > select BUILDTIME_TABLE_SORT > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > index 7748489fde1b..0ddd9c78f9f4 100644 > > --- a/include/linux/huge_mm.h > > +++ b/include/linux/huge_mm.h > > @@ -476,6 +476,7 @@ vm_fault_t do_huge_pmd_numa_page(struct vm_fault *vmf); > > extern struct folio *huge_zero_folio; > > extern unsigned long huge_zero_pfn; > > +extern atomic_t huge_zero_folio_is_static; > > static inline bool is_huge_zero_folio(const struct folio *folio) > > { > > @@ -494,6 +495,16 @@ static inline bool is_huge_zero_pmd(pmd_t pmd) > > struct folio *mm_get_huge_zero_folio(struct mm_struct *mm); > > void mm_put_huge_zero_folio(struct mm_struct *mm); > > +struct folio *__get_static_huge_zero_folio(void); > > + > > +static inline struct folio *get_static_huge_zero_folio(void) > > +{ > > + if (!IS_ENABLED(CONFIG_STATIC_HUGE_ZERO_FOLIO)) > > + return NULL; > > + if (likely(atomic_read(&huge_zero_folio_is_static))) > > + return huge_zero_folio; > > + return __get_static_huge_zero_folio();> +} > > static inline bool thp_migration_supported(void) > > { > > @@ -685,6 +696,11 @@ static inline int change_huge_pud(struct mmu_gather *tlb, > > { > > return 0; > > } > > + > > +static inline struct folio *get_static_huge_zero_folio(void) > > +{ > > + return NULL; > > +} > > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > > static inline int split_folio_to_list_to_order(struct folio *folio, > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 0287e8d94aea..14721171846f 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -835,6 +835,18 @@ config ARCH_WANT_GENERAL_HUGETLB > > config ARCH_WANTS_THP_SWAP > > def_bool n > > +config ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO > > + def_bool n > > + > > +config STATIC_HUGE_ZERO_FOLIO > > + bool "Allocate a PMD sized folio for zeroing" > > + depends on ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO > > + help > > + Typically huge_zero_folio, which is a PMD page of zeroes, is allocated > > + on demand and deallocated when not in use. This option will > > + allocate huge_zero_folio but it will never free it. > > + Not suitable for memory constrained systems. > > Maybe something like > > " > Without this config enabled, the huge zero folio is allocated on demand and > freed under memory pressure once no longer in use. To detect remaining users > reliably, references to the huge zero folio must be tracked precisely, so it > is commonly only available for mapping it into user page tables. > > With this config enabled, the huge zero folio can also be used for other > purposes that do not implement precise reference counting: it is still > allocated on demand, but never freed, allowing for more wide-spread use, > for example, when performing I/O similar to the traditional shared > zeropage." > > Not suitable for memory constrained systems. > " Sounds much better! I will add it. > > Should we make it clear that this is currently limited to THP configs? > > depends on TRANSPARENT_HUGEPAGE You are right. As we use the existing infrastructure, we do become dependent on THP. > > > + > > config MM_ID > > def_bool n > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > > index 5d8365d1d3e9..6c890a1482f3 100644 > > --- a/mm/huge_memory.c > > +++ b/mm/huge_memory.c > > @@ -75,6 +75,8 @@ static unsigned long deferred_split_scan(struct shrinker *shrink, > > static bool split_underused_thp = true; > > static atomic_t huge_zero_refcount; > > +static atomic_t huge_zero_static_fail_count __read_mostly; > > +atomic_t huge_zero_folio_is_static __read_mostly; > > struct folio *huge_zero_folio __read_mostly; > > unsigned long huge_zero_pfn __read_mostly = ~0UL; > > unsigned long huge_anon_orders_always __read_mostly; > > @@ -266,6 +268,32 @@ void mm_put_huge_zero_folio(struct mm_struct *mm) > > put_huge_zero_page(); > > } > > +#ifdef CONFIG_STATIC_HUGE_ZERO_FOLIO > > +struct folio *__get_static_huge_zero_folio(void) > > Do we want to play safe and have a > > if (unlikely(!slab_is_available())) > return NULL; > Yes, sounds good. > > +{ > > + /* > > + * If we failed to allocate a huge zero folio multiple times, > > + * just refrain from trying. > > + */ > > Hmmm, I wonder if we want to retry "some time later" again. Meaning, we'd > base it on the jiffies, maybe? > > See print_bad_pte() for an example. That is a good idea. I was thinking somethign like that while I was making the changes. This seems more logical. > > > + if (atomic_read(&huge_zero_static_fail_count) > 2) > > + return NULL; > > + > > We could make some smart decision regarding totalram_pages() and just > disable it. A bit tricky, we can do that as a follow-up. > oooh. Yeah, I will add it in my todos to make this as a follow up :) Thanks for all your comments David! Can I send it next series as a normal patch series instead of an RFC? It looks like this series is shaping up nicely. -- Pankaj
