Hello, On Thursday, July 22, 2010 11:06 AM Mark Brown wrote: > On Wed, Jul 21, 2010 at 08:41:12PM +0200, Micha?? Nazarewicz wrote: > > On Wed, 21 Jul 2010 20:24:58 +0200, Mark Brown > <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > >> I am currently working on making the whole thing more dynamic. I > imagine > > > > Yes, I think it will be much easier to be able to grab the regions at > > > startup but hopefully the allocation within those regions can be made > > > much more dynamic. This would render most of the configuration syntax > > > unneeded. > > > Not sure what you mean by the last sentence. Maybe we have different > > things in mind? > > I mean that if the drivers are able to request things dynamically and > have some knowledge of their own requirements then that removes the need > to manually specify exactly which regions go to which drivers which > means that most of the complexity of the existing syntax is not needed > since it can be figured out at runtime. 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. 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 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). With CMA approach we can create 2 memory regions for this case. One for gfx accelerator and the other for camera capture device, video decoder or jpeg decoder, because common usage analysis showed that these 3 devices usually are not used at the same time. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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>