Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Jul 22, 2010 at 11:25:48AM +0200, Marek Szyprowski wrote:

> The driver may specify memory requirements (like memory address range or
> alignment), but it cannot provide enough information to avoid or reduce
> memory fragmentation. More than one memory region can be perfectly used
> to reduce memory fragmentation IF common usage patterns are known. In
> embedded world usually not all integrated device are being used at the
> same time. This way some memory regions can be shared by 2 or more devices. 

I do have some passing familiarity with the area, typically a lot of the
features of a SoC won't get used at all at runtime on any given system.

> Just assume that gfx accelerator allocates memory is rather small chunks,
> but keeps it while relevant surface is being displayed or processed by
> application. It is not surprising that GUI (accelerated by the hardware
> engine) is used almost all the time on a mobile device. This usage pattern
> would produce a lot of fragmentation in the memory pool that is used by gfx
> accelerator. Then we want to run a camera capture device to take a 8Mpix

I'd expect that the devices would be able to reserve blocks of memory to
play with separately to the actual allocations (ie, allocate regions
like those on the command line) and things like the GPU would make use
of that.  I think you're already doing part of this?

> photo. This require a large contiguous buffer. If we try to allocate it from
> common pool it might happen that it is not possible (because of the
> fragmentation).

Sure, but none of this is saying to me that it's specifically important
to supply a static configuration via this textual configuration language
on the command line - half the problem is that you're trying to write
the configuration down in a format which is fairly tightly constrained
by needing to be there.  If the configuration is more dynamic there's a
lot more flexibility to either allow the system to figure things out
dynamically (which will hopefully work a lot of the time, for example in
your use case only the GPU really needs memory reserving).

Remember also that if you can configure this at runtime (as you say
you're working towards) then even if you have a fairly static
configuration you can inject it into the kernel from the application
layer rather than having to either hard code it in the image or bodge it
in via the command line.  This keeps the resource allocation joined up
with the application layer (which is after all what determines the
resource usage).