Re: [RFC v2 0/2] dmapool: Mitigate device-controllable mem. corruption

[Brian Johannesmeyer]

On Thu, Nov 21, 2024 at 11:06 AM Keith Busch <kbusch@xxxxxxxxxx> wrote:
> If you have the time, could you compare with using xarray instead?

Sure. Good idea.

**With the submitted patches applied AND using an xarray for
vaddr-to-block translations:**
```
dmapool test: size:16   align:16   blocks:8192 time:37954
dmapool test: size:64   align:64   blocks:8192 time:40036
dmapool test: size:256  align:256  blocks:8192 time:41942
dmapool test: size:1024 align:1024 blocks:2048 time:10964
dmapool test: size:4096 align:4096 blocks:1024 time:6101
dmapool test: size:68   align:32   blocks:8192 time:41307
```

The xarray approach shows a slight improvement in performance compared
to the maple tree approach.

FWIW, I implemented the two with slightly different semantics:
- In the maple tree implementation, I saved the `block`'s entire
`vaddr` range, allowing any `vaddr` within the `block` to be passed to
`dma_pool_free()`.
- In the xarray implementation, I saved only the `block's` base
`vaddr`, requiring `dma_pool_free()` to be called with the exact
`vaddr` returned by `dma_pool_alloc()`. This aligns with the DMA pool
API documentation, which specifies that the `vaddr` returned by
`dma_pool_alloc()` should be passed to `dma_pool_free()`.

Let me know if you'd like further adjustments.

Thanks,

Brian Johannesmeyer