linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: hverkuil@xs4all.nl, dwalker@codeaurora.org,
	linux@arm.linux.org.uk, corbet@lwn.net, p.osciak@samsung.com,
	broonie@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org, hvaibhav@ti.com,
	linux-mm@kvack.org, kyungmin.park@samsung.com,
	kgene.kim@samsung.com, zpfeffer@codeaurora.org,
	jaeryul.oh@samsung.com, m.szyprowski@samsung.com,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
Date: Fri, 20 Aug 2010 12:54:02 +0200	[thread overview]
Message-ID: <op.vhqgkcgj7p4s8u@localhost> (raw)
In-Reply-To: <20100820193328P.fujita.tomonori@lab.ntt.co.jp>

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

> On Fri, 20 Aug 2010 10:10:45 +0200
> **UNKNOWN CHARSET** <m.nazarewicz@samsung.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2010-08-20 10:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06 13:22 Michal Nazarewicz
2010-08-06 13:22 ` [PATCH/RFCv3 1/6] lib: rbtree: rb_root_init() function added Michal Nazarewicz
2010-08-06 13:22   ` [PATCH/RFCv3 2/6] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-08-06 13:22     ` [PATCH/RFCv3 3/6] mm: cma: Added SysFS support Michal Nazarewicz
2010-08-06 13:22       ` [PATCH/RFCv3 4/6] mm: cma: Added command line parameters support Michal Nazarewicz
2010-08-06 13:22         ` [PATCH/RFCv3 5/6] mm: cma: Test device and application added Michal Nazarewicz
2010-08-06 13:22           ` [PATCH/RFCv3 6/6] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-08-18  3:01 ` [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework Kyungmin Park
2010-08-19 14:47   ` Konrad Rzeszutek Wilk
2010-08-20  0:50     ` Michał Nazarewicz
2010-08-19 15:15   ` FUJITA Tomonori
2010-08-20  1:08     ` Michał Nazarewicz
2010-08-20  3:12       ` FUJITA Tomonori
2010-08-20  6:38         ` Michał Nazarewicz
2010-08-20  6:57           ` FUJITA Tomonori
2010-08-20  8:10             ` Michał Nazarewicz
2010-08-20 10:35               ` FUJITA Tomonori
2010-08-20 10:54                 ` Michał Nazarewicz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.vhqgkcgj7p4s8u@localhost \
    --to=m.nazarewicz@samsung.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=corbet@lwn.net \
    --cc=dwalker@codeaurora.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hvaibhav@ti.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jaeryul.oh@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=p.osciak@samsung.com \
    --cc=zpfeffer@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox