[PATCHv8 00/12] Contiguous Memory Allocator

[Tomasz Fujak]

Dear Mr. King,

AFAIK the CMA is the fourth attempt since 2008 taken to solve the
multimedia memory allocation issue on some embedded devices. Most
notably on ARM, that happens to be present in the SoCs we care about
along the IOMMU-incapable multimedia IPs.

I understand that you have your guidelines taken from the ARM
specification, but this approach is not helping us. The mainline kernel
is server- and desktop-centric for various reasons I am not going to
dwell into. We're trying hard to solve the physical memory fragmentation
issue for some time now, only to hear "this is not acceptable, go
somewhere else". So we did - the CMA is targeted towards mm, NOT the
ARM. While I do not exactly know how you see your role in ARM kernel
development, we have shown a few times that this issue is important for
us, and we'd like to solve it. So if you could give a glimpse of what is
acceptable, given the existing circumstances, we could possibly help
developing that solution. Namely:
1. ARM-compatible SoC
2. Multimedia IP blocks requiring large amounts of contiguous memory
2. No IOMMU or SG in said blocks
4. Unused memory reserved for said multimedia drivers should  be used by
the kernel
5. Multimedia allocation scenarios must always be working (under some
constraints of course), within sane time limit
6. The solution shall have minimal delta to upstream linux (none?)

While the obvious CMA uses are the ones you'd mostly like to avoid, we
haven't tried to post anything like that along.
This way no obvious spec abuse is made, and we minimize the delta to the
upstream - it's even better than current state, when you have dma
coherent memory doing exactly what you claim is forbidden (unpredictable
results could possibly happen).

As the feedback from the first CMA patches confirm, the issue we're
trying to solve here is real. Yet no real solution exists to my
knowledge. I understand the ARM holding my try to just wait till all the
relevant chips do have an IOMMU, but here and now there is a SOC we are
going to use. No IMOMMU, no SG. So would you please help us - or if for
some reason you can't, just not make our work any harder?

BTW why is the lowmem unmap not feasible? Is it the section entries in
the page tables scattered throughout the system? I was unable to find
the answer so far.

Best regards
-- 
Tomasz Fujak
Samsung Electronics Poland R&D

On 2010-12-23 13:19, Russell King - ARM Linux wrote:
> On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
>> Actually this contiguous memory allocator is a better replacement for
>> alloc_pages() which is used by dma_alloc_coherent(). It is a generic
>> framework that is not tied only to ARM architecture.
> ... which is open to abuse.  What I'm trying to find out is - if it
> can't be used for DMA, what is it to be used for?
>
> Or are we inventing an everything-but-ARM framework?
>
>>> In other words, do we _actually_ have a use for this which doesn't
>>> involve doing something like allocating 32MB of memory from it,
>>> remapping it so that it's DMA coherent, and then performing DMA
>>> on the resulting buffer?
>> This is an arm specific problem, also related to dma_alloc_coherent()
>> allocator. To be 100% conformant with ARM specification we would
>> probably need to unmap all pages used by the dma_coherent allocator
>> from the LOW MEM area. This is doable, but completely not related
>> to the CMA and this patch series.
> You've already been told why we can't unmap pages from the kernel
> direct mapping.
>
> Okay, so I'm just going to assume that CMA has _no_ _business_ being
> used on ARM, and is not something that should interest anyone in the
> ARM community.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>