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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]