[RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device memory management

On Wed, 21 Jul 2010 21:30:34 -0700
Zach Pfeffer [off-list ref] wrote:

On Wed, Jul 21, 2010 at 10:44:37AM +0900, FUJITA Tomonori wrote:

quoted

On Tue, 20 Jul 2010 15:20:01 -0700
Zach Pfeffer [off-list ref] wrote:

quoted

quoted

I'm not saying that it's reasonable to pass (or even allocate) a 1MB
buffer via the DMA API.

But given a bunch of large chunks of memory, is there any API that can
manage them (asked this on the other thread as well)?

What is the problem about mapping a 1MB buffer with the DMA API?

Possibly, an IOMMU can't find space for 1MB but it's not the problem
of the DMA API.

This goes to the nub of the issue. We need a lot of 1 MB physically
contiguous chunks. The system is going to fragment and we'll never get
our 12 1 MB chunks that we'll need, since the DMA API allocator uses
the system pool it will never succeed. For this reason we reserve a
pool of 1 MB chunks (and 16 MB, 64 KB etc...) to satisfy our
requests. This same use case is seen on most embedded "media" engines
that are getting built today.

We don't need a new abstraction to reserve some memory.

If you want pre-allocated memory pool per device (and share them with
some), the DMA API can for coherent memory (see
dma_alloc_from_coherent). You can extend the DMA API if necessary.