On Thu, 22 Jul 2010 12:52:03 +0200, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@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, 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