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

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Matthew Wilcox <willy@infradead.org> writes:

> On Tue, Mar 11, 2025 at 02:44:15PM +0100, Toke Høiland-Jørgensen wrote:
>> Pavel Begunkov <asml.silence@gmail.com> writes:
>> > If we're out of space in the page, why can't we use struct page *
>> > as indices into the xarray? Ala
>> >
>> > struct page *p = ...;
>> > xa_store(xarray, index=(unsigned long)p, p);
>> >
>> > Indices wouldn't be nicely packed, but it's still a map. Is there
>> > a problem with that I didn't consider?
>> 
>> Huh. As I just replied to Yunsheng, I was under the impression that this
>> was not supported. But since you're now the second person to suggest
>> this, I looked again, and it looks like I was wrong. There does indeed
>> seem to be other places in the kernel that does this.
>> 
>> As you say the indices won't be as densely packed, though. So I'm
>> wondering if using the bits in pp_magic would be better in any case to
>> get the better packing? I guess we can try benchmarking both approaches
>> and see if there's a measurable difference.
>
> This is an absolutely terrible idea, only proposed by those who have no
> understanding of how the XArray works.  It could not be more wasteful.

Alright, ACK, will stay with the xa_alloc() + stashing the id in
pp_magic (unless you come back and tell us there's some reason we can't
use those bits).

Do you mind if I send a patch to the xarray docs to explicitly spell out
that using pointers as keys is a bad idea? It's a bit implicit the way
it's phrased now, IMO.

-Toke