linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
To: m.nazarewicz@samsung.com
Cc: m.szyprowski@samsung.com, fujita.tomonori@lab.ntt.co.jp,
	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 19:17:42 +0900	[thread overview]
Message-ID: <20100722191658V.fujita.tomonori@lab.ntt.co.jp> (raw)
In-Reply-To: <op.vf8oa80k7p4s8u@pikus>

On Thu, 22 Jul 2010 11:50:58 +0200
**UNKNOWN CHARSET** <m.nazarewicz@samsung.com> wrote:

> On Thu, 22 Jul 2010 11:35:07 +0200, FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > You have the feature in the wrong place.
> >
> > Your example: a camera driver and a video driver can share 20MB, then
> > they want 20MB exclusively.
> >
> > You can reserve 20MB and make them share it. Then you can reserve 20MB
> > for both exclusively.
> >
> > You know how the whole system works. Adjust drivers (probably, with
> > module parameters).
> 
> So you are talking about moving complexity from the CMA core to the drivers.

I don't think that adjusting some drivers about how they use memory is
so complicated. Just about how much and exclusive or share.

And adjusting drivers in embedded systems is necessary anyway.

It's too complicated feature that isn't useful for the majority.


> > When a video driver needs 20MB to work properly, what's the point of
> > releasing the 20MB for others then trying to get it again later?
> 
> If you have a video driver that needs 20MiB and a camera that needs 20MiB
> will you reserve 40MiB total? That's 20MiB wasted if on your system those
> two can never work at the same time. So do you reserve 20MiB and share?
> That won't work if on your system the two can work at the same time.
> 
> With CMA you can configure the kernel for both cases.

See above. You can do without such complicated framework.


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

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."?

--
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-07-22 10:17 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 [this message]
2010-07-22 10:55                 ` Mark Brown
2010-07-22 11:49                 ` Michał Nazarewicz
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=20100722191658V.fujita.tomonori@lab.ntt.co.jp \
    --to=fujita.tomonori@lab.ntt.co.jp \
    --cc=corbet@lwn.net \
    --cc=hvaibhav@ti.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.nazarewicz@samsung.com \
    --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