Matthew Wilcox <willy@xxxxxxxxxxxxx> writes: > 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. Ah, excellent, thanks for the pointer! Out of curiosity, why "bump"? Is that a term of art somewhere? And in the meantime (until those patches land), do you see any reason why we can't squat on the middle bits of page->pp_magic (AKA page->lru) like I'm doing in v2[0] of this patch? -Toke [0] https://lore.kernel.org/r/20250309124719.21285-1-toke@xxxxxxxxxx
