I’ll go ahead and prepare a V3 patch series with the following updates:
- Using an xarray for vaddr-to-block translations, which improves the
performance of free operations.
- Removing the minimum DMA block size constraint, as it is no longer necessary.
Let me know if there are any additional sug
On Thu, Nov 21, 2024 at 11:06 AM Keith Busch 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
dmap
On Thu, Nov 21, 2024 at 10:31:11AM -0700, Brian Johannesmeyer wrote:
> **With the submitted patches applied AND using a maple tree to improve
> the performance of vaddr-to-block translations:**
If you have the time, could you compare with using xarray instead?
> Here's my quick thoughts at this late hour, though I might have
> something else tomorrow. If the links are external to the dma addr
> being freed, then I think you need to change the entire alloc/free API
> to replace the dma_addr_t handle with a new type, like a tuple of
>
> { dma_addr_t, pri
On Wed, Nov 20, 2024 at 02:58:54PM -0700, Brian Johannesmeyer wrote:
> 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 r
> 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
On Wed, Nov 20, 2024 at 01:29:19AM -0800, Christoph Hellwig wrote:
> On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote:
> > **Performance**. I evaluated the patch set's performance by running the
> > `DMAPOOL_TEST` test with `DMAPOOL_DEBUG` enabled and with/without the
> > patches
On Wed, Nov 20, 2024 at 01:29:19AM -0800, Christoph Hellwig wrote:
> On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote:
> > We discovered a security-related issue in the DMA pool allocator.
> >
> > V1 of our RFC was submitted to the Linux kernel security team. They
> > recommende
On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote:
> We discovered a security-related issue in the DMA pool allocator.
>
> V1 of our RFC was submitted to the Linux kernel security team. They
> recommended submitting it to the relevant subsystem maintainers and the
> hardening mai
On Tue, Nov 19, 2024 at 3:15 PM Greg KH wrote:
> I know I said it privately, but I'll say it here in public, very cool
> finding, this is nice work!
Thanks! I appreciate your earlier feedback as well.
> You had mentioned that the size:68 numbers were going to be re-run, has
> that happened and t
On Tue, Nov 19, 2024 at 09:55:27PM +0100, Brian Johannesmeyer wrote:
> We discovered a security-related issue in the DMA pool allocator.
>
> V1 of our RFC was submitted to the Linux kernel security team. They
> recommended submitting it to the relevant subsystem maintainers and the
> hardening mai
We discovered a security-related issue in the DMA pool allocator.
V1 of our RFC was submitted to the Linux kernel security team. They
recommended submitting it to the relevant subsystem maintainers and the
hardening mailing list instead, as they did not consider this an explicit
security issue. Th
12 matches
Mail list logo
