Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool

[Matthew Wilcox <willy@infradead.org>]

On Mon, Mar 10, 2025 at 06:26:23PM +0100, Toke Høiland-Jørgensen wrote:
> Matthew Wilcox <willy@infradead.org> 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.