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