On Thu, Apr 20, 2023 at 06:42:17PM +0200, Alexander Lobakin wrote: > When there's no recycling of pages, then yes. And since recycling is > done asynchronously, sometimes new allocations happen either way. > Anyways, that was roughly a couple years ago right when you introduced > dma_alloc_noncoherent(). Things might've been changed since then. > I could try again while next is closed (i.e. starting this Sunday), the > only thing I'd like to mention: Page Pool allocates pages via > alloc_pages_bulk_array_node(). Bulking helps a lot (and PP uses bulks of > 16 IIRC), explicit node setting helps when Rx queues are distributed > between several nodes. We can then have one struct device for several nodes. > As I can see, there's now no function to allocate in bulks and no > explicit node setting option (e.g. mlx5 works around this using > set_dev_node() + allocate + set_dev_node(orig_node)). Could such options > be added in near future? That would help a lot switching to the > functions intended for use when DMA mappings can stay for a long time. > >From what I see from the code, that shouldn't be a problem (except for > non-direct DMA cases, where we'd need to introduce new callbacks or > extend the existing ones). So the node hint is something we can triviall pass through, and something the mlx5 maintainers should have done from the beginning instead of this nasty hack. Patches gladly accepted. A alloc_pages_bulk_array_node-like allocator also seems doable, we just need to make sure it has a decent fallback as I don't think we can wire it up to all the crazy legacy iommu drivers. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
