Re: [PATCH] mm: make folio page count functions return unsigned

[Matthew Wilcox <willy@infradead.org>]

On Tue, Aug 26, 2025 at 06:00:41PM -0400, Aristeu Rozanski wrote:
> some actually expect an int (e.g. memcg1_charge_statistics()), it'd be a good
> idea to get those fixed.

Yes.

> > Then, e.g., -1 will be (unsigned int)0xffffffff, and casting that to 
> > "long" means trouble, because we wouldn't sign-extend properly and get 
> > (long)0x00000000ffffffff.
> > 
> > Using "unsigned long" instead work perfectly fine.
> > 
> > e.g., -1 will be (unsigned long)0xffffffffffffffff. Passing that to a 
> > function that expects "long" or "unsigned long" works as expected.
> 
> We could run into problems if folio_nr_pages() ever returns an unsigned long
> larger than LONG_MAX :^)

I feel comfortable saying that we'll never support a folio size larger
than 2^31 bytes on 32-bit or 2^63 bytes on 64-bit because folio_size()
returns a size_t so that constrains us.  That means folio_nr_pages()
must lie in the range [1..2^19] or [1..2^51] respectively.  We're never
going to support PAGE_SIZE smaller than 4KiB; nobody's interested in
designing hardware to support smaller page sizes.

We are likely to see folio_nr_pages() be larger than 2^31 at some point.
arm64 supports 2^13 pages per level, so a PMD is 2^13, a PUD is 2^26
and a P4D is 2^39 pages.  That's an utterly impractical page size for
most uses, but just wait until the AI people decide that it saaves them
a fraction of a joule per calculation.  I'm not putting any work into
supporting that at this point, but I'm also trying not to do anything
that makes adding that support harder.