Re: [PATCH v1 11/36] mm: limit folio/compound page sizes in problematic kernel configs
Wei Yang <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <20250828073755.gyq5cyafrxb7lnw2@master> |
On Thu, Aug 28, 2025 at 12:01:15AM +0200, 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. > >Reviewed-by: Zi Yan <[email protected]> >Acked-by: Mike Rapoport (Microsoft) <[email protected]> >Signed-off-by: David Hildenbrand <[email protected]> Reviewed-by: Wei Yang <[email protected]> -- Wei Yang Help you, Help me