From: Michał Nazarewicz on
> 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.

On Thu, 22 Jul 2010 14:46:00 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote:
> 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).

That's why command line is only intended as a way to overwrite the
defaults which are provided by the platform. In a final product,
configuration should be specified in platform code and not on
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.
>
> 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.

Command line was one of the reasons for using textual interface. I surely
wouldn't go with parsing the strings if I could manage without it allowing
easy platform-level configuration at the same time.

>> 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.

Platform can specify something like:

cma_defaults("reg=20M", "*/*=reg");

which would make all the drivers share 20 MiB region by default. I'm also
thinking if something like:

cma_defaults("reg=20M", "*/*=*");

(ie. asterisk instead of list of regions) should be allowed. It would make
the default to be that all allocations are performed from all named regions.
I'll see how much coding is that and maybe add it.

--
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
On Thu, Jul 22, 2010 at 03:24:26PM +0200, Michał Nazarewicz wrote:

> That's why command line is only intended as a way to overwrite the
> defaults which are provided by the platform. In a final product,
> configuration should be specified in platform code and not on
> command line.

Yeah, agreed though I'm not convinced we can't do it via userspace
(initrd would give us a chance to do stuff early) or just kernel
rebuilds.

> >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.

> Platform can specify something like:

> cma_defaults("reg=20M", "*/*=reg");

> which would make all the drivers share 20 MiB region by default. I'm also
> thinking if something like:

Yes, exactly - probably you can even have a default region backed by
normal vmalloc() RAM which would at least be able to take a stab at
working by default.
--
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
On Thu, 22 Jul 2010 15:40:56 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote:

> On Thu, Jul 22, 2010 at 03:24:26PM +0200, Michał Nazarewicz wrote:
>
>> That's why command line is only intended as a way to overwrite the
>> defaults which are provided by the platform. In a final product,
>> configuration should be specified in platform code and not on
>> command line.
>
> Yeah, agreed though I'm not convinced we can't do it via userspace
> (initrd would give us a chance to do stuff early) or just kernel
> rebuilds.

If there's any other easy way of overwriting platform's default I'm happy
to listen. :)

>> >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.
>
>> Platform can specify something like:
>
>> cma_defaults("reg=20M", "*/*=reg");
>
>> which would make all the drivers share 20 MiB region by default.
>
> Yes, exactly - probably you can even have a default region backed by
> normal vmalloc() RAM which would at least be able to take a stab at
> working by default.

Not sure what you mean here. vmalloc() allocated buffers cannot be used
with CMA since they are not contiguous in memory.

--
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
On Thu, Jul 22, 2010 at 04:58:43PM +0200, Michał Nazarewicz wrote:
> On Thu, 22 Jul 2010 15:40:56 +0200, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote:

> >Yeah, agreed though I'm not convinced we can't do it via userspace
> >(initrd would give us a chance to do stuff early) or just kernel
> >rebuilds.

> If there's any other easy way of overwriting platform's default I'm happy
> to listen. :)

Netlink or similar, for example?

> >Yes, exactly - probably you can even have a default region backed by
> >normal vmalloc() RAM which would at least be able to take a stab at
> >working by default.

> Not sure what you mean here. vmalloc() allocated buffers cannot be used
> with CMA since they are not contiguous in memory.

Sorry, thinko - I just meant allocated at runtime. It'd fail a a lot of
the time so might not be worth bothering.
--
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: Pawel Osciak on
Hi Zach,

>Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote:
>On Tue, Jul 20, 2010 at 05:51:25PM +0200, Michal Nazarewicz wrote:

(snip)

>> +* Contiguous Memory Allocator
>> +
>> + The Contiguous Memory Allocator (CMA) is a framework, which allows
>> + setting up a machine-specific configuration for physically-contiguous
>> + memory management. Memory for devices is then allocated according
>> + to that configuration.
>> +
>> + The main role of the framework is not to allocate memory, but to
>> + parse and manage memory configurations, as well as to act as an
>> + in-between between device drivers and pluggable allocators. It is
>> + thus not tied to any memory allocation method or strategy.
>> +
>
>This topic seems very hot lately. I recently sent out a few RFCs that
>implement something called a Virtual Contiguous Memory Manager that
>does what this patch does, and works for IOMMU and works for CPU
>mappings. It also does multihomed memory targeting (use physical set 1
>memory for A allocations and use physical memory set 2 for B
>allocations). Check out:
>
>mm: iommu: An API to unify IOMMU, CPU and device memory management
>mm: iommu: A physical allocator for the VCMM
>mm: iommu: The Virtual Contiguous Memory Manager
>
>It unifies IOMMU and physical mappings by creating a one-to-one
>software IOMMU for all devices that map memory physically.
>
>It looks like you've got some good ideas though. Perhaps we can
>leverage each other's work.

Yes, I have read your RFCs when they originally come out and I think
that CMA could be used as a physical memory allocator for VCMM, if such
a need arises. Of course this would only make sense in special cases.
One idea I have is that this could be useful if we wanted to have
a common kernel for devices with and without an IOMMU. This way the
same virtual address spaces could be set up on top of different
allocators for different systems and use discontiguous memory for
SoCs with an IOMMU and contiguous for SoCs without it. What do you
think?

I am aware that you have your own physical memory allocator, but from
what you wrote, you use pools of contiguous memory consisting of
indivisible, fixed-size blocks (which is of course a good idea in the
presence of an IOMMU). Moreover, those advanced region traits and
sharing specification features of CMA are a must for us.

I don't perceive VCMM and CMA as competing solutions for the same
problem, they solve different problems and I believe could not only
coexist, but be used together in specific use cases.


Best regards
--
Pawel Osciak
Linux Platform Group
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/