On Thu, Aug 21, 2025 at 10:06:26PM +0200, David Hildenbrand wrote: > As discussed recently with Linus, nth_page() is just nasty and we would > like to remove it. > > To recap, the reason we currently need nth_page() within a folio is because > on some kernel configs (SPARSEMEM without SPARSEMEM_VMEMMAP), the > memmap is allocated per memory section. > > While buddy allocations cannot cross memory section boundaries, hugetlb > and dax folios can. > > So crossing a memory section means that "page++" could do the wrong thing. > Instead, nth_page() on these problematic configs always goes from > page->pfn, to the go from (++pfn)->page, which is rather nasty. > > Likely, many people have no idea when nth_page() is required and when > it might be dropped. > > We refer to such problematic PFN ranges and "non-contiguous pages". > If we only deal with "contiguous pages", there is not need for nth_page(). > > Besides that "obvious" folio case, we might end up using nth_page() > within CMA allocations (again, could span memory sections), and in > one corner case (kfence) when processing memblock allocations (again, > could span memory sections).
I browsed the patches and it looks great to me, thanks for doing this Jason
