Re: [PATCH 0/9] lib/folio_pool: Direct-Map Large Folio Pool & Scratchpad bump allocators

On 8/17/26 19:22, Jim Cromie via B4 Relay wrote:
> Introduce two light-weight bump allocators backed directly by compound
> folio pages from the buddy allocator (skipping SLUB metadata overhead):

We are running into a bit of a naming problem here: folios are really supposed
to describe things that we will map to user space, whereby we have to track
mapping/index/mapcount etc. That's really just anon + pagecache memory.

Right now that naming difference doesn't matter, because each compound page
really is a folio.

But once we start decoupling folios from the rest (memdescs), we really only
expect anon+pagecache to resemble "folios".

There will be other compound page types (similar to slab pages), and things like
page_folio() will fail for them (like slab pages). And we are actually working
on making page_folio() fail earlier for anything that didn't go through
page_rmappable_folio() as part of the (folio) allocation.

So, does what you do here fit the definition of folios, or is it really just
some kind of compound pages?

-- 
Cheers,

David