mm: cma: Contiguous Memory Allocator added
in [Kernel]
|
From: FUJITA Tomonori on 22 Jul 2010 06:20 On Thu, 22 Jul 2010 11:50:58 +0200 **UNKNOWN CHARSET** <m.nazarewicz(a)samsung.com> wrote: > 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. I don't think that adjusting some drivers about how they use memory is so complicated. Just about how much and exclusive or share. And adjusting drivers in embedded systems is necessary anyway. It's too complicated feature that isn't useful for the majority. > > 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. See above. You can do without such complicated framework. > 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. What's your point? The majority of features (e.g. scsi, ata, whatever) works in that way. They are useful on some and not on some. Are you saying, "my system needs this feature. You can disable it if you don't need it. so let's merge it. it doesn't break your system."? -- 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 22 Jul 2010 07:00 On Thu, Jul 22, 2010 at 07:17:42PM +0900, FUJITA Tomonori wrote: > And adjusting drivers in embedded systems is necessary anyway. Actually for embedded systems we make strong efforts to ensure that drivers do not need tuning per system and that where this is unavoidable we separate the configuration from the driver itself (using either a driver specific interface or a subsystem one depending on the genericness) so that the driver does not need modifying. -- 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 07:30 On Thu, 22 Jul 2010 12:52:03 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > 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? In the patchset I've sent it is not possible but I already have a version that supports this. Regions can be registered at any time. What's more, such regions can be completely private to drivers that register them. > 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). There are two command line arguments to consider: cma and cma_map. The first one, I believe, should be there as to specify the regions that are to be reserved. Drivers and platform will still be able to add their own regions but I believe that in vest majority of cases, it will be enough to just pass the list of region on a command line. Alternatively, instead of the textual description of platform could provide an array of regions it want reserved. It would remove like 50 lines of code from CMA core (in the version I have on my drive at least, where part of the syntax was simplified) however it would remove the possibility to easily change the configuration from command line (ie. no need to recompile which is handy when you need to optimise this and test various configurations) and would add more code to the platform initialisation code, ie: instead of: cma_defaults("reg1=20M;reg2=20M", NULL); one would have to define an array with the regions descriptors. Personally, I don't see much benefits from this. As of the second parameter, "cma_map", which validating and parsing is like 150 lines of code, I consider it handy because you can manage all the memory regions in one place and it moves some of the complexity from device drivers to CMA. I'm also working on providing a sysfs entry so that the it would be possible to change the mapping at runtime. For example, consider a driver I have mentioned before: video decoder that needs to allocate memory from 3 different regions (for firmware, the first bank of memory and the second bank of memory). With CMA you define the regions: cma=vf=1M/128K;a=20M;b=20M(a)512M; and then map video driver to them like so: cma_map=video/a=a;video/b=b;video/f=vf I agree that parsing it is not nice but thanks to it, all you need to do in the driver is: cma_alloc(dev, "a", ...) cma_alloc(dev, "b", ...) cma_alloc(dev, "f", ...) Without cma_map you'd have to pass names of the region to the driver and make the driver use those. It would also make it impossible or hard to change the mapping once the driver is loaded. What I'm trying to say is that I'm trying to move complexity out of the drivers into the framework (as I believe that's what frameworks are for). As of dynamic, runtime, automatic configuration, I don't really see that. I'm still wondering how to make as little configuration necessary as possible but I don't think everything can be done in such a way. -- 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 22 Jul 2010 07:50 > On Thu, 22 Jul 2010 11:50:58 +0200 > **UNKNOWN CHARSET** <m.nazarewicz(a)samsung.com> wrote: >> So you are talking about moving complexity from the CMA core to the drivers. On Thu, 22 Jul 2010 12:17:42 +0200, FUJITA Tomonori <fujita.tomonori(a)lab.ntt.co.jp> wrote: > I don't think that adjusting some drivers about how they use memory is > so complicated. Just about how much and exclusive or share. I don't believe it is that simple. If shared then with what? What if foo-dev can share with bar-dev and baz-dev can share with qux-dev? Also, even if its 10 lines of code in each driver isn't it worth removing from the driver and not let it worry about it? The configuration needs to be specified one way of another, my approach with CMA was to centralise it so that drivers do not need to worry about it. > And adjusting drivers in embedded systems is necessary anyway. It should not be... > It's too complicated feature that isn't useful for the majority. Please consider what I've written in discussion with Mark Brown. >> 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. > What's your point? The majority of features (e.g. scsi, ata, whatever) > works in that way. They are useful on some and not on some. My point is, that you can configure CMA the way you want... > Are you saying, "my system needs this feature. You can disable it if > you don't need it. so let's merge it. it doesn't break your system."? No. I'm saying many of the embedded systems without IO MMU need to be able to allocate contiguous memory chunks. I'm also saying there is at least one system where some non-trivial configuration is needed and adding configuration handling to CMA is not as big of a cost as one may imagine. -- 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 22 Jul 2010 08:50
On Thu, Jul 22, 2010 at 01:30:52PM +0200, Michał Nazarewicz wrote: > The first one, I believe, should be there as to specify the regions > that are to be reserved. Drivers and platform will still be able to > add their own regions but I believe that in vest majority of cases, > it will be enough to just pass the list of region on a command line. The command line is a real pain for stuff like this since it's not usually committed to revision control so robustly and it's normally more painful to change the bootloader to pass the desired command line in than it is to change either the kernel or userspace (some bootloaders are just completely unconfigurable without reflashing, and if your only recovery mechanism is JTAG that can be a bit of a concern). > Alternatively, instead of the textual description of platform could > provide an array of regions it want reserved. It would remove like > 50 lines of code from CMA core (in the version I have on my drive at > least, where part of the syntax was simplified) however it would > remove the possibility to easily change the configuration from > command line (ie. no need to recompile which is handy when you need > to optimise this and test various configurations) and would add more > code to the platform initialisation code, ie: instead of: > cma_defaults("reg1=20M;reg2=20M", NULL); > one would have to define an array with the regions descriptors. > Personally, I don't see much benefits from this. I think it'd be vastly more legible, especially if the list of regions gets large. I had thought the only reason for the text format was to put it onto the command line. > I agree that parsing it is not nice but thanks to it, all you need to > do in the driver is: > cma_alloc(dev, "a", ...) > cma_alloc(dev, "b", ...) > cma_alloc(dev, "f", ...) > Without cma_map you'd have to pass names of the region to the driver > and make the driver use those. I agree that a mapping facility for the names is essential, especially if drivers need to share regions. > What I'm trying to say is that I'm trying to move complexity out of > the drivers into the framework (as I believe that's what frameworks > are for). It sounds like apart from the way you're passing the configuration in you're doing roughly what I'd suggest. I'd expect that in a lot of cases the map could be satisfied from the default region so there'd be no need to explicitly set one up. -- 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/ |