On 2024/11/7 3:55, Alexander Duyck wrote:
|
...
>
> Is there any specific reason for why we need to store the pages
> instead of just scanning the page tables to look for them? We should
> already know how many we need to look for and free. If we were to just
> scan the page structs and identify the page pool pages that are
> pointing to our pool we should be able to go through and clean them
> up. It won't be the fastest approach, but this should be an
> exceptional case to handle things like a hot plug removal of a device
> where we can essentially run this in the background before we free the
> device.
Does 'scanning the page tables' mean scaning the array of 'struct page *',
like vmemmap/memmap?
I am not sure if there is any existing pattern or API to scan that array?
Does it fall under the catalog of poking into the internals of mm subsystem?
For exmaple, there seems to be different implemenation for that array depending
on CONFIG_SPARSEMEM* config.
Also, I am not sure how much time it may take if we have to scan the array
of 'struct page *' for all the memory in the system.
>
> Then it would just be a matter of modifying the pool so that it will
> drop support for doing DMA unmapping and essentially just become a
> place for the freed pages to go to die.
>
If I understand it correctly, the above seems to be what this patch is
trying to do by clearing pool->dma_map after doing the dma unmapping for
the inflight pages.
