On 21 Aug 2025, at 16:49, David Hildenbrand wrote: > On 21.08.25 22:46, Zi Yan wrote: >> 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. > > Yeah, but the old comment was wrong (there is DAX). > > I can add here "currently expect (e.g., hugetlfs, dax)."
Sounds good. Best Regards, Yan, Zi
