I posted a similar patch series back in 2018: https://lore.kernel.org/linux-mm/73ec1f52-d758-05df-fb6a-41d269e910d0@xxxxxxxxxxxxxxx/ https://lore.kernel.org/linux-mm/15ff502d-d840-1003-6c45-bc17f0d81262@xxxxxxxxxxxxxxx/ https://lore.kernel.org/linux-mm/1288e597-a67a-25b3-b7c6-db883ca67a25@xxxxxxxxxxxxxxx/ I initially used a red-black tree keyed by the DMA address, but then for v2 of the patchset I put the dma pool info directly into struct page and used virt_to_page() to get at it. But it turned out that was a bad idea because not all architectures have struct page backing dma_alloc_coherent(): https://lore.kernel.org/linux-kernel/20181206013054.GI6707@xxxxxxxxxxx/ I intended to go back and resubmit the red-black tree version, but I was too busy at the time and forgot about it. A few days ago I finally decided to update the patches and submit them upstream. I found your recent dmapool xarray patches by searching the mailing list archive to see if anyone else was working on something similar. Using the following as a benchmark: modprobe mpt3sas drivers/scsi/mpt3sas/mpt3sas_base.c _base_allocate_chain_dma_pool loop dma_pool_alloc(ioc->chain_dma_pool) rmmod mpt3sas drivers/scsi/mpt3sas/mpt3sas_base.c _base_release_memory_pools() loop dma_pool_free(ioc->chain_dma_pool) Here are the benchmark results showing the speedup from the patchsets: modprobe rmmod orig 1x 1x xarray 5.2x 186x rbtree 9.3x 269x It looks like my red-black tree version is faster than the v1 of the xarray patch on this benchmark at least, although the mpt3sas usage of dmapool is hardly typical. I will try to get some testing done on my patchset and post it next week. Tony Battersby Cybernetics
