linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michal Nazarewicz <m.nazarewicz@samsung.com>,
	linux-mm@kvack.org, Daniel Walker <dwalker@codeaurora.org>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Jonathan Corbet <corbet@lwn.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Pawel Osciak <p.osciak@samsung.com>,
	Russell King <linux@arm.linux.org.uk>,
	Zach Pfeffer <zpfeffer@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
Date: Sat, 28 Aug 2010 16:16:09 +0200	[thread overview]
Message-ID: <1283004969.1975.3530.camel@laptop> (raw)
In-Reply-To: <201008281558.23501.hverkuil@xs4all.nl>

On Sat, 2010-08-28 at 15:58 +0200, Hans Verkuil wrote:
> > Isn't the proposed CMA thing vulnerable to the exact same problem? If
> > you allow sharing of regions and plug some allocator in there you get
> > the same problem. If you can solve it there, you can solve it for any
> > kind of reservation scheme.
> 
> Since with cma you can assign a region exclusively to a driver you can ensure
> that this problem does not occur. Of course, if you allow sharing then you will
> end up with the same type of problem unless you know that there is only one
> driver at a time that will use that memory.

I think you could do the same thing, the proposed page allocator
solutions still needs to manage pageblock state, you can manage those
the same as you would your cma regions -- the difference is that you get
the option of letting the rest of the system use the memory in a
transparent manner if you don't need it.


> There is obviously a trade-off. I was just wondering how costly it is.
> E.g. would it be a noticeable delay making 64 MB memory available in this
> way on a, say, 600 MHz ARM. 

Right, dunno really, rather depends on the memory bandwidth of your arm
device I suspect. It is something you'd have to test. 

In case the machine isn't fast enough, there really isn't anything you
can do but keep the memory empty at all times; unless of course the
device in question needs it.

--
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-28 14:16 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-20  9:50 [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework Michal Nazarewicz
2010-08-20  9:50 ` [PATCH/RFCv4 1/6] lib: rbtree: rb_root_init() function added Michal Nazarewicz
2010-08-20  9:50   ` [PATCH/RFCv4 2/6] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-08-20  9:50     ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Michal Nazarewicz
2010-08-20  9:50       ` [PATCH/RFCv4 4/6] mm: cma: Added command line parameters support Michal Nazarewicz
2010-08-20  9:50         ` [PATCH/RFCv4 5/6] mm: cma: Test device and application added Michal Nazarewicz
2010-08-20  9:50           ` [PATCH/RFCv4 6/6] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-08-25 20:37       ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Konrad Rzeszutek Wilk
2010-08-26  1:20         ` Michał Nazarewicz
2010-08-25 20:32     ` [PATCH/RFCv4 2/6] mm: cma: Contiguous Memory Allocator added Konrad Rzeszutek Wilk
2010-08-26  1:22       ` Michał Nazarewicz
2010-08-26  6:25     ` [PATCH/RFCv4.1 " Michal Nazarewicz
2010-08-26 13:47     ` [PATCH/RFCv4 " Mel Gorman
2010-08-27  2:09       ` Michał Nazarewicz
2010-08-28 12:37     ` Hans Verkuil
2010-08-29  1:48       ` Michał Nazarewicz
2010-08-20 13:15 ` [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework Peter Zijlstra
2010-08-25 22:58   ` Andrew Morton
2010-08-25 23:26     ` Daniel Walker
2010-08-26  1:38       ` Michał Nazarewicz
2010-08-25 23:31     ` Jonathan Corbet
2010-08-26  1:38       ` Pawel Osciak
2010-08-26  1:49       ` Michał Nazarewicz
2010-08-26  2:49       ` Minchan Kim
2010-08-26  3:04         ` Minchan Kim
2010-08-26  8:20         ` Peter Zijlstra
2010-08-26  9:29           ` Minchan Kim
2010-08-26 10:06             ` Peter Zijlstra
2010-08-26 10:21               ` Minchan Kim
2010-08-26 11:05                 ` Peter Zijlstra
2010-08-26  0:58     ` KAMEZAWA Hiroyuki
2010-08-26  2:12       ` Michał Nazarewicz
2010-08-26  2:50         ` KAMEZAWA Hiroyuki
2010-08-26  3:44           ` KAMEZAWA Hiroyuki
2010-08-26  4:01             ` Michał Nazarewicz
2010-08-26  4:39               ` KAMEZAWA Hiroyuki
2010-08-26  5:54               ` Américo Wang
2010-08-26  4:06             ` Minchan Kim
2010-08-26  4:14               ` Minchan Kim
2010-08-26  4:30               ` KAMEZAWA Hiroyuki
2010-08-26  9:36                 ` Minchan Kim
2010-08-27  8:16                   ` KAMEZAWA Hiroyuki
2010-08-27  8:37                     ` Peter Zijlstra
2010-09-02  8:54                     ` KAMEZAWA Hiroyuki
2010-09-03 10:29                       ` KAMEZAWA Hiroyuki
2010-09-05 15:57                         ` Minchan Kim
2010-09-06  0:08                           ` KAMEZAWA Hiroyuki
2010-08-26  1:22     ` Pawel Osciak
2010-08-26  2:40     ` Michał Nazarewicz
2010-08-26  8:18       ` Peter Zijlstra
2010-08-26 10:18       ` Mel Gorman
2010-08-28 13:08     ` Hans Verkuil
2010-08-28 13:34       ` Peter Zijlstra
2010-08-28 13:58         ` Hans Verkuil
2010-08-28 14:16           ` Peter Zijlstra [this message]
2010-08-30  8:27     ` Clemens Ladisch
2010-08-26  1:28   ` Michał Nazarewicz
2010-08-26  8:17     ` Peter Zijlstra
2010-08-27  2:41       ` Michał Nazarewicz
2010-08-26 10:12   ` Mel Gorman

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=1283004969.1975.3530.camel@laptop \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=corbet@lwn.net \
    --cc=dwalker@codeaurora.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hverkuil@xs4all.nl \
    --cc=konrad.wilk@oracle.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.nazarewicz@samsung.com \
    --cc=m.szyprowski@samsung.com \
    --cc=mel@csn.ul.ie \
    --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).