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). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>