Re: [RFC: DMA_PMD 00/22] DMA_PMD: PMD_SIZE-backed IO buffer pools

On 12/10/2026 8:43 pm, David Hildenbrand (Arm) wrote:

On 10/12/26 16:45, Luigi Rizzo wrote:

quoted

On Mon, Oct 12, 2026 at 3:51 PM David Hildenbrand (Arm)
[off-list ref] wrote:

quoted

On 10/3/26 23:22, Luigi Rizzo wrote:

quoted

Here is a subsystem called DMA_PMD on which I would like feedback on
architecture, possible enhancements, or kernel components that could be
reused to avoid duplication.

Here is a feedback to a subsystem called DMA_PMD ;)

Why is basing this on PMDs (and embedding it in the name) the right approach?

On architctures with large PMDs (512 MiB on arm64 with 64k), would we really
want to use 512 MiB pages, or rather something smaller (e.g., 2 MiB) that might
possibly also have TLB benefits (cont-pte)?

I had to call it something... an earlier prototype used the name IOMMU_2M,
but I didn't want to suggest that the design was limited to 2M (it is not).

Aside from the name, the _current_ prototype restricts to 2M allocations,
exactly because too large units are expensive and wasteful.

In the code, decoupling the allocation size from the PMD size is trivial.

Yeah, we should do that.

We should probably just find a way to describe that this is a POOL that focuses
on physical contiguity in some configured granularity.

And since it's intended for DMA we could call it dma_pool and oh look it already exists...

Sure the current implementation is capped at PAGE_SIZE for allocation (and thus mapping too), but I don't see why that couldn't just be made more flexible.

Thanks,
Robin.