From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: kyungmin.park@samsung.com, linux-mm@kvack.org,
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,
hverkuil@xs4all.nl, kgene.kim@samsung.com,
zpfeffer@codeaurora.org, jaeryul.oh@samsung.com,
linux-media@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
Subject: Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework
Date: Fri, 20 Aug 2010 08:38:10 +0200 [thread overview]
Message-ID: <op.vhp4pws27p4s8u@localhost> (raw)
In-Reply-To: <20100820121124Z.fujita.tomonori@lab.ntt.co.jp>
On Fri, 20 Aug 2010 05:12:50 +0200, FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
>> 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.
>
> You can create something similar to the existing API for memory
> allocator.
That may be tricky. cma_alloc() takes four parameters each of which is
required for CMA. No other existing set of API uses all those arguments.
This means, CMA needs it's own, somehow unique API. I don't quite see
how the APIs may be unified or "made similar". Of course, I'm gladly
accepting suggestions.
>> 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.
>
> Well, why can't we do the above before the inclusion?
Because it's quite a bit of work and instead of diverting my attention I'd
prefer to make CMA as good as possible and then integrate it with other
subsystems. Also, adding the integration would change the patch from being
4k lines to being like 40k lines.
What I'm trying to say is that I don't consider that a work for now but
rather a further enchantments.
> Anyway, I think that comments from mm people would be helpful to merge
> this.
Yes, I agree.
--
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>
next prev parent reply other threads:[~2010-08-20 6:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 13:22 [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework 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 [this message]
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
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.vhp4pws27p4s8u@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;
as well as URLs for NNTP newsgroup(s).