mm: cma: Contiguous Memory Allocator added
in [Kernel]
|
From: Mark Brown on 22 Jul 2010 05:10 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(a)opensource.wolfsonmicro.com> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marek Szyprowski on 22 Jul 2010 05:40 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(a)opensource.wolfsonmicro.com> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 22 Jul 2010 05:40 On Wed, 21 Jul 2010 23:01:42 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > On Wed, 2010-07-21 at 22:56 +0200, Michał Nazarewicz wrote: >> On Wed, 21 Jul 2010 22:45:43 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: >> > Your not hearing the issues.. IT'S TOO COMPLEX! Please remove it. >> >> Remove what exactly? > > Remove the command line option and all related code, or make it all a > debug option. How convenient... you have stripped the part of my mail where I described why this is request have no sense. I'll quote myself then: >> The command line parameter? It's like 50 lines of code, so I don't >> see any benefits. As such, I'm not going to add bunch of #ifdefs just to remove 50 lines of code. >> The possibility to specify the configuration? It would defy the whole >> purpose of CMA, so I won't do that. Simply as that. We work with a platform where whole of the functionality provided by CMA is required (many regions, region start address, region alignment, device->region mapping). This means, what I keep repeating and you keep ignoring, that the complexity will be there if not as a parsing code then moved to the platform initialisation code and drivers code. One of the purposes of CMA is to hide the complexity inside CMA framework so device driver authors and platform maintainers can use a simpler interface. Some time age (like year or two) I've posted some other solution to the problem which served our purpose just well and had very little complexity in it. Unfortunately, customising that solution was quite hard (required changes to a header file and adding modifying code for reserving space). Also, in this old solution, adding or removing regions required device drivers to be modified. This was not nice, not nice at all. True, however, the core wasn't complex. So when you say remove the complicity I say: I have been there, it's ugly. > Arguing with me isn't going to help your cause. It's you who keep repeating “remove it, it's to complex” without hearing my arguments. I keep trying to show that all of the functionality is required and is being used on our development platform. If your hardware does not require that complexity... well, you're one lucky man. Unfortunately, we are not, and we need a complex solution to work with complex hardware. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 22 Jul 2010 05:40 On Thu, 22 Jul 2010 09:28:02 +0200 Marek Szyprowski <m.szyprowski(a)samsung.com> wrote: > > About the framework, it looks too complicated than we actually need > > (the command line stuff looks insane). > > Well, this command line stuff was designed to provide a way to configure > memory allocation for devices with very sophisticated memory requirements. You have the feature in the wrong place. Your example: a camera driver and a video driver can share 20MB, then they want 20MB exclusively. You can reserve 20MB and make them share it. Then you can reserve 20MB for both exclusively. You know how the whole system works. Adjust drivers (probably, with module parameters). > > Why can't we have something simpler, like using memblock to reserve > > contiguous memory at boot and using kinda mempool to share such memory > > between devices? > > There are a few problems with such simple approach: > > 1. It does not provide all required functionality for our multimedia > devices. The main problem is the fact that our multimedia devices > require particular kind of buffers to be allocated in particular memory > bank. Then add 2 more requirements: a proper alignment (for some of them > it is even 128Kb) and particular range of addresses requirement (some > buffers must be allocated at higher addresses than the firmware). > This is very hard to achieve with such simple allocator. When a video driver needs 20MB to work properly, what's the point of releasing the 20MB for others then trying to get it again later? Even with the above example (two devices never use the memory at the same time), the driver needs memory regularly. What's the point of split the 20MB to small chunks and allocate them to others? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 22 Jul 2010 05:50
On Thu, 22 Jul 2010 11:35:07 +0200, FUJITA Tomonori <fujita.tomonori(a)lab.ntt.co.jp> wrote: > You have the feature in the wrong place. > > Your example: a camera driver and a video driver can share 20MB, then > they want 20MB exclusively. > > You can reserve 20MB and make them share it. Then you can reserve 20MB > for both exclusively. > > You know how the whole system works. Adjust drivers (probably, with > module parameters). So you are talking about moving complexity from the CMA core to the drivers. Ie. instead of configuring regions and mapping via CMA command line parameters, the whole configuration is pushed to modules. We consider that suboptimal because it (i) does not reduce complexity -- it just moves it somewhere else, (ii) spreads the complexity to many modules instead of single core of CMA, and (iii) spreads the configuration to many modules instead of keeping it in one place. > When a video driver needs 20MB to work properly, what's the point of > releasing the 20MB for others then trying to get it again later? If you have a video driver that needs 20MiB and a camera that needs 20MiB will you reserve 40MiB total? That's 20MiB wasted if on your system those two can never work at the same time. So do you reserve 20MiB and share? That won't work if on your system the two can work at the same time. With CMA you can configure the kernel for both cases. > Even with the above example (two devices never use the memory at the > same time), the driver needs memory regularly. What's the point of > split the 20MB to small chunks and allocate them to others? Lost you there... If something does not make sense on your system you don't configure CMA to do that. That's one of the points of CMA. What does not make sense on your platform may make perfect sense on some other system, with some other drivers maybe. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |