Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework

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

 



On Thu, 19 Aug 2010 17:15:12 +0200, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:

On Wed, 18 Aug 2010 12:01:35 +0900
Kyungmin Park <kyungmin.park@xxxxxxxxxxx> wrote:

Are there any comments or ack?

We hope this method included at mainline kernel if possible.
It's really needed feature for our multimedia frameworks.

You got any comments from mm people?

Virtually, this adds a new memory allocator implementation that steals
some memory from memory allocator during boot process. Its API looks
completely different from the API for memory allocator. That doesn't
sound appealing to me much. This stuff couldn't be integrated well
into memory allocator?

What kind of integration do you mean?  I see three levels:

1. Integration on API level meaning that some kind of existing API is used
   instead of new cma_*() calls.  CMA adds notion of devices and memory
   types which is new to all the other APIs (coherent has notion of devices
   but that's not enough).  This basically means that no existing API can be
   used for CMA.  On the other hand, removing notion of devices and memory
   types would defeat the whole purpose of CMA thus destroying the solution
   that CMA provides.

2. Reuse of memory pools meaning that memory reserved by CMA can then be
   used by other allocation mechanisms.  This is of course possible.  For
   instance coherent could easily be implemented as a wrapper to CMA.
   This is doable and can be done in the future after CMA gets more
   recognition.

3. Reuse of algorithms meaning that allocation algorithms used by other
   allocators will be used with CMA regions.  This is doable as well and
   can be done in the future.

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