On 21 Aug 2025, at 16:06, David Hildenbrand wrote: > Let's limit the maximum folio size in problematic kernel config where > the memmap is allocated per memory section (SPARSEMEM without > SPARSEMEM_VMEMMAP) to a single memory section. > > Currently, only a single architectures supports ARCH_HAS_GIGANTIC_PAGE > but not SPARSEMEM_VMEMMAP: sh. > > Fortunately, the biggest hugetlb size sh supports is 64 MiB > (HUGETLB_PAGE_SIZE_64MB) and the section size is at least 64 MiB > (SECTION_SIZE_BITS == 26), so their use case is not degraded. > > As folios and memory sections are naturally aligned to their order-2 size > in memory, consequently a single folio can no longer span multiple memory > sections on these problematic kernel configs. > > nth_page() is no longer required when operating within a single compound > page / folio. > > Signed-off-by: David Hildenbrand <da...@redhat.com> > --- > include/linux/mm.h | 22 ++++++++++++++++++---- > 1 file changed, 18 insertions(+), 4 deletions(-) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 77737cbf2216a..48a985e17ef4e 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2053,11 +2053,25 @@ static inline long folio_nr_pages(const struct folio > *folio) > return folio_large_nr_pages(folio); > } > > -/* Only hugetlbfs can allocate folios larger than MAX_ORDER */ > -#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE > -#define MAX_FOLIO_ORDER PUD_ORDER > -#else > +#if !defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) > +/* > + * We don't expect any folios that exceed buddy sizes (and consequently > + * memory sections). > + */ > #define MAX_FOLIO_ORDER MAX_PAGE_ORDER > +#elif defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP) > +/* > + * Only pages within a single memory section are guaranteed to be > + * contiguous. By limiting folios to a single memory section, all folio > + * pages are guaranteed to be contiguous. > + */ > +#define MAX_FOLIO_ORDER PFN_SECTION_SHIFT > +#else > +/* > + * There is no real limit on the folio size. We limit them to the maximum we > + * currently expect.
The comment about hugetlbfs is helpful here, since the other folios are still limited by buddy allocator’s MAX_ORDER. > + */ > +#define MAX_FOLIO_ORDER PUD_ORDER > #endif > > #define MAX_FOLIO_NR_PAGES (1UL << MAX_FOLIO_ORDER) > -- > 2.50.1 Otherwise, Reviewed-by: Zi Yan <z...@nvidia.com> Best Regards, Yan, Zi
