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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <op.vhppgaxq7p4s8u@localhost>
Date:	Fri, 20 Aug 2010 03:08:24 +0200
From:	Michał Nazarewicz <m.nazarewicz@...sung.com>
To:	kyungmin.park@...sung.com,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-mm@...ck.org, dwalker@...eaurora.org, linux@....linux.org.uk,
	corbet@....net, p.osciak@...sung.com,
	broonie@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org,
	hvaibhav@...com, hverkuil@...all.nl, kgene.kim@...sung.com,
	zpfeffer@...eaurora.org, jaeryul.oh@...sung.com,
	linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	m.szyprowski@...sung.com
Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework

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

> On Wed, 18 Aug 2010 12:01:35 +0900
> Kyungmin Park <kyungmin.park@...sung.com> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/