On Mon, Mar 10, 2025 at 10:13:32AM +0100, Toke Høiland-Jørgensen wrote: > Yunsheng Lin <yunshenglin0825@xxxxxxxxx> writes: > > Also, Using the more space in 'struct page' for the page_pool seems to > > make page_pool more coupled to the mm subsystem, which seems to not > > align with the folios work that is trying to decouple non-mm subsystem > > from the mm subsystem by avoid other subsystem using more of the 'struct > > page' as metadata from the long term point of view. > > This seems a bit theoretical; any future changes of struct page would > have to shuffle things around so we still have the ID available, > obviously :) See https://kernelnewbies.org/MatthewWilcox/Memdescs and more immediately https://kernelnewbies.org/MatthewWilcox/Memdescs/Path pagepool is going to be renamed "bump" because it's a bump allocator and "pagepool" is a nonsense name. I haven't looked into it in a lot of detail yet, but in the not-too-distant future, struct page will look like this (from your point of view): struct page { unsigned long flags; unsigned long memdesc; int _refcount; // 0 for bump union { unsigned long private; atomic_t _mapcount; // maybe used by bump? not sure }; }; 'memdesc' will be a pointer to struct bump with the bottom four bits of that pointer indicating that it's a struct bump pointer (and not, say, a folio or a slab). So if you allocate a multi-page bump, you'll get N of these pages, and they'll all point to the same struct bump where you'll maintain your actual refcount. And you'll be able to grow struct bump to your heart's content. I don't know exactly what struct bump looks like, but the core mm will have no requirements on you.
