Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added

[MichaÅ Nazarewicz]

On Wed, 21 Jul 2010 19:35:50 +0200, Daniel Walker <dwalker@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/