mm: cma: Contiguous Memory Allocator added
in [Kernel]
|
From: Daniel Walker on 21 Jul 2010 14:20 On Wed, 2010-07-21 at 20:11 +0200, Michał Nazarewicz wrote: > >> > (btw, these strings your creating yikes, talk about confusing ..) > >> > >> They are not that scary really. Let's look at cma: > >> > >> a=10M;b=10M > >> > >> Split it on semicolon: > >> > >> a=10M > >> b=10M > >> > >> and you see that it defines two regions (a and b) 10M each. > > > > I think your assuming a lot .. I've never seen the notation before I > > wouldn't assuming there's regions or whatever .. > > That's why there is documentation with grammar included. :) > > >> As of cma_map: > >> > >> camera,video=a;jpeg,scaler=b > >> > >> Again split it on semicolon: > >> > >> camera,video=a > >> jpeg,scaler=b > >> > >> Now, substitute equal sign by "use(s) region(s)": > >> > >> camera,video use(s) region(s): a > >> jpeg,scaler use(s) region(s): b > >> > >> No black magic here. ;) > > > > It way too complicated .. Users (i.e. not programmers) has to use > > this .. > > Not really. This will probably be used mostly on embedded systems > where users don't have much to say as far as hardware included on the > platform is concerned, etc. Once a phone, tablet, etc. is released > users will have little need for customising those strings. You can't assume that user won't want to reflash their own kernel on the device. Your assuming way too much. If you assume they do want their own kernel then they would need this string from someplace. If your right and this wouldn't need to change, why bother allowing it to be configured at all ? Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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 21 Jul 2010 14:20 On Wed, 21 Jul 2010 19:35:50 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > On Wed, 2010-07-21 at 14:01 +0200, Michał Nazarewicz wrote: > >> What you are asking for is: >> >> cma=a=100M cma_map=*/*=a >> >> All devices will share the same region so that "if the video driver isn't >> using the memory" then "something else can use it". (please excuse me quoting >> you, it was stronger then me ;) ). > > Ok .. > >> Driver has to little information to say whether it really stopped using >> memory. Maybe the next call will be to allocate buffers for frames and >> initialise the chip? Sure, some “good enough” defaults can be provided >> (and the framework allows that) but still platform architect might need >> more power. > > I think your talking more about optimization .. You can take that into > account .. Well, yes, that's one of the points: to minimise amount of memory reserved for devices. >> > (btw, these strings your creating yikes, talk about confusing ..) >> >> They are not that scary really. Let's look at cma: >> >> a=10M;b=10M >> >> Split it on semicolon: >> >> a=10M >> b=10M >> >> and you see that it defines two regions (a and b) 10M each. > > I think your assuming a lot .. I've never seen the notation before I > wouldn't assuming there's regions or whatever .. That's why there is documentation with grammar included. :) >> As of cma_map: >> >> camera,video=a;jpeg,scaler=b >> >> Again split it on semicolon: >> >> camera,video=a >> jpeg,scaler=b >> >> Now, substitute equal sign by "use(s) region(s)": >> >> camera,video use(s) region(s): a >> jpeg,scaler use(s) region(s): b >> >> No black magic here. ;) > > It way too complicated .. Users (i.e. not programmers) has to use > this .. Not really. This will probably be used mostly on embedded systems where users don't have much to say as far as hardware included on the platform is concerned, etc. Once a phone, tablet, etc. is released users will have little need for customising those strings. On desktop computers on the other hand, the whole framework may be completely useless as devices are more likely to have IO map or scatter/getter capabilities. Plus, as I mentioned above, some “good enough” defaults can be provided. >> >> One of the purposes of the CMA framework is to make it let device >> >> drivers completely forget about the memory management and enjoy >> >> a simple API. >> > >> > The driver, and it's maintainer, are really the best people to know how >> > much memory they need and when it's used/unused. You don't really want >> > to architect them out. >> >> This might be true if there is only one device but even then it's not >> always the case. If many devices need physically-contiguous memory >> there is no way for them to communicate and share memory. For best >> performance someone must look at them and say who gets what. > > How do you think regular memory allocation work? I mean there's many > devices that all need different amounts of memory and they get along. > Yet your saying it's not possible . Regular memory allocation either does not allow you to allocate big chunks of memory (kmalloc) or uses MMU (vmalloc). The purpose of CMA is to provide a framework for allocators of big physically-contiguous chunks of memory. If a driver needs several KiB it just uses kmalloc() which handles such allocations just fine. However, we are taking about 6MiB full-HD frame or a photo from 5 megapixel camera. Currently, drivers are developed which create their own mechanism for allocating such chunks of memory. Often based on bootmem. CMA will unify all those mechanism and let it easier to manage them plus will allow for many drivers to share regions. -- 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: Mark Brown on 21 Jul 2010 14:30 On Wed, Jul 21, 2010 at 04:31:35PM +0200, Micha?? Nazarewicz wrote: > On Wed, 21 Jul 2010 15:52:30 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > > If this does need to be configured per system would having platform data > > of some kind in the kernel not be a sensible a place to do it, > The current version (and the next version I'm working on) of the code > has cma_defaults() call. It is intended to be called from platform > initialisation code to provide defaults. So the command line is just a way of overriding that? That makes things a lot nicer - normally the device would use the defaults and the command line would be used in development. > > or even > > having a way of configuring this at runtime (after all, the set of > > currently active users may vary depending on the current configuration > > and keeping everything allocated all the time may be wasteful)? > I am currently working on making the whole thing more dynamic. I imagine > the list of regions would stay pretty much the same after kernel has > started (that's because one cannot reliably allocate new big contiguous > memory regions) but it will be possible to change the set of rules, etc. 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. -- 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 21 Jul 2010 14:40 > On Wed, 2010-07-21 at 20:11 +0200, Michał Nazarewicz wrote: >> Not really. This will probably be used mostly on embedded systems >> where users don't have much to say as far as hardware included on the >> platform is concerned, etc. Once a phone, tablet, etc. is released >> users will have little need for customising those strings. On Wed, 21 Jul 2010 20:19:08 +0200, Daniel Walker <dwalker(a)codeaurora.org> wrote: > You can't assume that user won't want to reflash their own kernel on the > device. Your assuming way too much. If user is clever enough to reflash a phone she will find the strings easy especially that they are provided from: (i) bootloader which is even less likely to be reflashed and if someone do reflash bootloader she is a guru who'd know how to make the strings; or (ii) platform defaults which will be available with the rest of the source code for the platform. > If you assume they do want their own kernel then they would need this > string from someplace. If your right and this wouldn't need to change, > why bother allowing it to be configured at all ? Imagine a developer who needs to recompile the kernel and reflash the device each time she wants to change the configuration... Command line arguments seems a better option for development. And the configuration is needed because it is platform-dependent so it needs to be set for each platform. -- 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: Michał Nazarewicz on 21 Jul 2010 14:50
On Wed, 21 Jul 2010 20:24:58 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Wed, Jul 21, 2010 at 04:31:35PM +0200, Micha?? Nazarewicz wrote: >> On Wed, 21 Jul 2010 15:52:30 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > >> > If this does need to be configured per system would having platform data >> > of some kind in the kernel not be a sensible a place to do it, > >> The current version (and the next version I'm working on) of the code >> has cma_defaults() call. It is intended to be called from platform >> initialisation code to provide defaults. > > So the command line is just a way of overriding that? That makes things > a lot nicer - normally the device would use the defaults and the command > line would be used in development. Correct. >> > or even >> > having a way of configuring this at runtime (after all, the set of >> > currently active users may vary depending on the current configuration >> > and keeping everything allocated all the time may be wasteful)? > >> I am currently working on making the whole thing more dynamic. I imagine >> the list of regions would stay pretty much the same after kernel has >> started (that's because one cannot reliably allocate new big contiguous >> memory regions) but it will be possible to change the set of rules, etc. > > 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? -- 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/ |