On Mon, Mar 10, 2025 at 06:26:23PM +0100, Toke Høiland-Jørgensen wrote: > Matthew Wilcox <willy@xxxxxxxxxxxxx> writes: > > 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? https://en.wikipedia.org/wiki/Region-based_memory_management (and the term "bump allocator" has a number of hits in your favourite search engine) > 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? I haven't had time to dig into this series. I'm trying to get a bunch of things finished before LSFMM.
