[PATCH] mm: Move nth_page from folio_page into folio_next

[PATCH] mm: Move nth_page from folio_page into folio_next

[Herbert Xu]

Discontiguous memory may require the use of nth_page instead of adding
to struct page arithmetically.  However, discontiguous memory cannot
exist within a single folio.

The function folio_page is mostly used for accessing a page within
a folio, therefore using nth_page for it is overkill.

Move it to the only place where it's needed, which is folio_next.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 7b1068ddcbb7..5f63ee0770f7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2115,7 +2115,7 @@ static inline int thp_nr_pages(struct page *page)
  */
 static inline struct folio *folio_next(struct folio *folio)
 {
-	return (struct folio *)folio_page(folio, folio_nr_pages(folio));
+	return (struct folio *)nth_page(&folio->page, folio_nr_pages(folio));
 }
 
 /**
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 36d283552f80..ebba355c45a5 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -275,7 +275,7 @@ static __always_inline unsigned long _compound_head(const struct page *page)
  * check that the page number lies within @folio; the caller is presumed
  * to have a reference to the page.
  */
-#define folio_page(folio, n)	nth_page(&(folio)->page, n)
+#define folio_page(folio, n)	(&(folio)->page + (n))
 
 static __always_inline int PageTail(const struct page *page)
 {
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] mm: Move nth_page from folio_page into folio_next

[Matthew Wilcox]

On Thu, Mar 13, 2025 at 12:40:34PM +0800, Herbert Xu wrote:
> Discontiguous memory may require the use of nth_page instead of adding
> to struct page arithmetically.  However, discontiguous memory cannot
> exist within a single folio.

That isn't true.  HugeTLB can construct a folio which crosses a
contiguity boundary.

Re: [PATCH] mm: Move nth_page from folio_page into folio_next

[Herbert Xu]

On Thu, Mar 13, 2025 at 12:25:50PM +0000, Matthew Wilcox wrote:
>
> That isn't true.  HugeTLB can construct a folio which crosses a
> contiguity boundary.

Thanks.  So thea means we do need to use nth_page when iterating
through a folio or a scatterlist generated from a folio.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] mm: Move nth_page from folio_page into folio_next

[Zi Yan]

On 13 Mar 2025, at 21:18, Herbert Xu wrote:

> On Thu, Mar 13, 2025 at 12:25:50PM +0000, Matthew Wilcox wrote:
>>
>> That isn't true.  HugeTLB can construct a folio which crosses a
>> contiguity boundary.
>
> Thanks.  So thea means we do need to use nth_page when iterating
> through a folio or a scatterlist generated from a folio.

When you know the folio is hugetlb with gigantic order. Folios
come out of buddy allocator are all within contiguity boundaries.
To be precise, the boundary here means a section boundary.

In addition, nth_page() is a trivial addition for SPARSEMEM_VMEMMAP
or FLATMEM. For SPARSEMEM && !SPARSEMEM_VMEMMAP, it needs to use
pfn for the calculation.

Best Regards,
Yan, Zi