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] [day] [month] [year] [list]

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

On Fri, 20 Aug 2010 12:35:01 +0200, FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> wrote:

> On Fri, 20 Aug 2010 10:10:45 +0200
> **UNKNOWN CHARSET** <m.nazarewicz@...sung.com> wrote:
>
>> > I wrote "similar to the existing API', not "reuse the existing API".
>>
>> Yes, but I don't really know what you have in mind.  CMA is similar to various
>> APIs in various ways: it's similar to any allocator since it takes
>> size in bytes,
>
> why don't take gfp_t flags?

Because they are insufficient.  Either that or I don't understand gfp_t.

With CMA, platform can define many memory types.  For instance, if there are
two memory bans there can be two memory types for the two banks.  For at least one
of the device I'm in contact with, another type for it's firmware is also needed.
Bottom line is that there may be possibly many types which won't map to gfp_t.

> Something like dev_alloc_page is more appropriate name?

Two things: I'd prefer a "cma" prefix rather then "dev" and I think it should
be "pages", right? Then, size should be given in pages rather then bytes.

Nonetheless, I don't really see at the moment why this should be better.

> Or something similar to dmapool API (mm/dmapool.c) might work
> better. The purpose of dmapool API is creating a pool for consistent
> memory per device. It's similar to yours, creating a pool for
> contiguous memory per device(s)?

I'll try to look at it later on and think about it.  I'm still somehow reluctant
to change the names but still, thank you for suggestions.

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