From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: m.szyprowski@samsung.com, corbet@lwn.net, linux-mm@kvack.org,
p.osciak@samsung.com, xiaolin.zhang@intel.com, hvaibhav@ti.com,
robert.fekete@stericsson.com, marcus.xm.lorentzon@stericsson.com,
linux-kernel@vger.kernel.org, kyungmin.park@samsung.com
Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added
Date: Thu, 22 Jul 2010 13:49:26 +0200 [thread overview]
Message-ID: <op.vf8tsock7p4s8u@pikus> (raw)
In-Reply-To: <20100722191658V.fujita.tomonori@lab.ntt.co.jp>
> On Thu, 22 Jul 2010 11:50:58 +0200
> **UNKNOWN CHARSET** <m.nazarewicz@samsung.com> wrote:
>> So you are talking about moving complexity from the CMA core to the drivers.
On Thu, 22 Jul 2010 12:17:42 +0200, FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> I don't think that adjusting some drivers about how they use memory is
> so complicated. Just about how much and exclusive or share.
I don't believe it is that simple. If shared then with what? What if
foo-dev can share with bar-dev and baz-dev can share with qux-dev?
Also, even if its 10 lines of code in each driver isn't it worth
removing from the driver and not let it worry about it?
The configuration needs to be specified one way of another, my approach
with CMA was to centralise it so that drivers do not need to worry about
it.
> And adjusting drivers in embedded systems is necessary anyway.
It should not be...
> It's too complicated feature that isn't useful for the majority.
Please consider what I've written in discussion with Mark Brown.
>> Lost you there... If something does not make sense on your system you
>> don't configure CMA to do that. That's one of the points of CMA. What
>> does not make sense on your platform may make perfect sense on some
>> other system, with some other drivers maybe.
> What's your point? The majority of features (e.g. scsi, ata, whatever)
> works in that way. They are useful on some and not on some.
My point is, that you can configure CMA the way you want...
> Are you saying, "my system needs this feature. You can disable it if
> you don't need it. so let's merge it. it doesn't break your system."?
No. I'm saying many of the embedded systems without IO MMU need to be
able to allocate contiguous memory chunks. I'm also saying there is at
least one system where some non-trivial configuration is needed and
adding configuration handling to CMA is not as big of a cost as one may
imagine.
--
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-07-22 11:48 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 15:51 [PATCH 0/4] The Contiguous Memory Allocator Michal Nazarewicz
2010-07-20 15:51 ` [PATCH 1/4] lib: rbtree: rb_root_init() function added Michal Nazarewicz
2010-07-20 15:51 ` [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-07-20 15:51 ` [PATCH 3/4] mm: cma: Test device and application added Michal Nazarewicz
2010-07-20 15:51 ` [PATCH 4/4] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-07-20 18:15 ` [PATCH 2/4] mm: cma: Contiguous Memory Allocator added Daniel Walker
2010-07-20 19:14 ` Michał Nazarewicz
2010-07-20 19:38 ` Daniel Walker
2010-07-21 12:01 ` Michał Nazarewicz
2010-07-21 17:35 ` Daniel Walker
2010-07-21 18:11 ` Michał Nazarewicz
2010-07-21 18:19 ` Daniel Walker
2010-07-21 18:38 ` Michał Nazarewicz
2010-07-21 18:58 ` Daniel Walker
2010-07-21 19:21 ` Michał Nazarewicz
2010-07-21 19:37 ` Daniel Walker
2010-07-21 19:53 ` Michał Nazarewicz
2010-07-21 20:03 ` Daniel Walker
2010-07-21 20:22 ` Michał Nazarewicz
2010-07-21 20:34 ` Daniel Walker
2010-07-21 20:43 ` Michał Nazarewicz
2010-07-21 20:45 ` Daniel Walker
2010-07-21 20:56 ` Michał Nazarewicz
2010-07-21 21:01 ` Daniel Walker
2010-07-22 9:34 ` Michał Nazarewicz
2010-07-21 13:52 ` Mark Brown
2010-07-21 14:31 ` Michał Nazarewicz
2010-07-21 18:24 ` Mark Brown
2010-07-21 18:41 ` Michał Nazarewicz
2010-07-22 9:06 ` Mark Brown
2010-07-22 9:25 ` Marek Szyprowski
2010-07-22 10:52 ` Mark Brown
2010-07-22 11:30 ` Michał Nazarewicz
2010-07-22 12:46 ` Mark Brown
2010-07-22 13:24 ` Michał Nazarewicz
2010-07-22 13:40 ` Mark Brown
2010-07-22 14:58 ` Michał Nazarewicz
2010-07-22 15:05 ` Mark Brown
2010-07-20 20:52 ` Jonathan Corbet
2010-07-21 10:16 ` Michał Nazarewicz
2010-07-21 0:12 ` Jonathan Corbet
2010-07-22 5:37 ` FUJITA Tomonori
2010-07-22 7:28 ` Marek Szyprowski
2010-07-22 9:35 ` FUJITA Tomonori
2010-07-22 9:50 ` Michał Nazarewicz
2010-07-22 10:17 ` FUJITA Tomonori
2010-07-22 10:55 ` Mark Brown
2010-07-22 11:49 ` Michał Nazarewicz [this message]
2010-07-22 4:54 ` Zach Pfeffer
2010-07-22 7:49 ` Marek Szyprowski
2010-07-23 7:06 ` Pawel Osciak
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.vf8tsock7p4s8u@pikus \
--to=m.nazarewicz@samsung.com \
--cc=corbet@lwn.net \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hvaibhav@ti.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=marcus.xm.lorentzon@stericsson.com \
--cc=p.osciak@samsung.com \
--cc=robert.fekete@stericsson.com \
--cc=xiaolin.zhang@intel.com \
/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).