> You should probably Cc Keith as the person who most recently did major
> work on the dmpool code and might still remember how it works.
Thank you for adding him, and apologies for not including him initially.
> The intrusive list was overlayed in the freed blocks for spatial
> optimizations. If you're moving these field outside of it (I'll have to
> review the patch on lore), you can probably relax the minimum dma block
> size too since we don't need to hold the data structure information in
> it.
I see. AFAICT, relaxing the minimum DMA block size would just mean
removing these lines from `dma_pool_create()`:
```
if (size < sizeof(struct dma_block))
size = sizeof(struct dma_block);
```
> Could you rerun your tests without DMAPOOL_DEBUG enabled? That's the
> more interesting kernel setup for performance comparisions.
Sure, that makes sense. Here are the results with DMAPOOL_DEBUG disabled:
**Without the patches applied:**
```
dmapool test: size:16 align:16 blocks:8192 time:11860
dmapool test: size:64 align:64 blocks:8192 time:11951
dmapool test: size:256 align:256 blocks:8192 time:12287
dmapool test: size:1024 align:1024 blocks:2048 time:3134
dmapool test: size:4096 align:4096 blocks:1024 time:1686
dmapool test: size:68 align:32 blocks:8192 time:12050
```
**With the patches applied:**
```
dmapool test: size:16 align:16 blocks:8192 time:34432
dmapool test: size:64 align:64 blocks:8192 time:62262
dmapool test: size:256 align:256 blocks:8192 time:238137
dmapool test: size:1024 align:1024 blocks:2048 time:61386
dmapool test: size:4096 align:4096 blocks:1024 time:75342
dmapool test: size:68 align:32 blocks:8192 time:88243
```
These results are consistent across multiple runs. It seems that with
DMAPOOL_DEBUG disabled, the patches introduce a significant
performance hit. Let me know if you have any suggestions or further
tests you'd like me to run.
Thanks,
Brian Johannesmeyer
