For the 'papering over' part, it seems it is about if we want to paper over
different kicking/flushing or paper over unmapping using different DMA API.
Also page_pool is not really a allocator, instead it is more like a pool
based on different allocator, such as buddy allocator or devmem allocator.
I am not sure it makes much to do the flushing when page_pool_destroy() is
called if the buddy allocator behind the page_pool is not under memory
pressure yet.
For the 'leaked' part mentioned above, I am agreed that it should be fixed
if we have a clear and unified definition of 'leaked'ï¼? for example, is it
allowed to keep the cache outstanding forever if the allocator is not under
memory pressure and not ask for the releasing of its memory?
Doesn't it make more sense to use something like shrinker_register() mechanism
to decide whether to do the flushing?
IOW, maybe it makes more sense that the allocator behind the page_pool should
be deciding whether to do the kicking/flushing, and maybe page_pool should also
use the shrinker_register() mechanism to empty its cache when necessary instead
of deciding whether to do the kicking/flushing.
So I am not even sure if it is appropriate to do the cache kicking/flushing
during waiting, not to mention the indefinite time to do the kicking/flushing.
>
> -Toke
>
>
> Patch to flush the deferred free list when taking down a netdevice;
> compile-tested only:
As mentioned above, doesn't it have the time window below?
CPU 0 CPU1
unregister_netdev() .
. .
flush_all_backlogs() .
. .
. skb_attempt_defer_free()
. .
. .
. .
. .
