From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [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.
WARNING: multiple messages have this Message-ID (diff)
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.
WARNING: multiple messages have this Message-ID (diff)
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>
next prev parent reply other threads:[~2010-08-28 14:16 UTC|newest]
Thread overview: 180+ 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 ` Michal Nazarewicz
2010-08-20 9:50 ` 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 ` Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` [PATCH/RFCv4 2/6] mm: cma: Contiguous Memory Allocator added Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` 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 ` Michal Nazarewicz
2010-08-20 9:50 ` 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 ` Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` [PATCH/RFCv4 6/6] arm: Added CMA to Aquila and Goni Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-20 9:50 ` Michal Nazarewicz
2010-08-25 20:37 ` [PATCH/RFCv4 3/6] mm: cma: Added SysFS support Konrad Rzeszutek Wilk
2010-08-25 20:37 ` Konrad Rzeszutek Wilk
2010-08-25 20:37 ` Konrad Rzeszutek Wilk
2010-08-26 1:20 ` Michał Nazarewicz
2010-08-26 1:20 ` Michał Nazarewicz
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-25 20:32 ` Konrad Rzeszutek Wilk
2010-08-25 20:32 ` Konrad Rzeszutek Wilk
2010-08-26 1:22 ` Michał Nazarewicz
2010-08-26 1:22 ` Michał Nazarewicz
2010-08-26 1:22 ` Michał Nazarewicz
2010-08-26 6:25 ` [PATCH/RFCv4.1 " Michal Nazarewicz
2010-08-26 6:25 ` Michal Nazarewicz
2010-08-26 6:25 ` Michal Nazarewicz
2010-08-26 13:47 ` [PATCH/RFCv4 " Mel Gorman
2010-08-26 13:47 ` Mel Gorman
2010-08-26 13:47 ` Mel Gorman
2010-08-27 2:09 ` Michał Nazarewicz
2010-08-27 2:09 ` Michał Nazarewicz
2010-08-27 2:09 ` Michał Nazarewicz
2010-08-28 12:37 ` Hans Verkuil
2010-08-28 12:37 ` Hans Verkuil
2010-08-28 12:37 ` Hans Verkuil
2010-08-29 1:48 ` Michał Nazarewicz
2010-08-29 1:48 ` Michał Nazarewicz
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-20 13:15 ` Peter Zijlstra
2010-08-20 13:15 ` Peter Zijlstra
2010-08-25 22:58 ` Andrew Morton
2010-08-25 22:58 ` Andrew Morton
2010-08-25 22:58 ` Andrew Morton
2010-08-25 23:26 ` Daniel Walker
2010-08-25 23:26 ` Daniel Walker
2010-08-25 23:26 ` Daniel Walker
2010-08-26 1:38 ` Michał Nazarewicz
2010-08-26 1:38 ` Michał Nazarewicz
2010-08-26 1:38 ` Michał Nazarewicz
2010-08-25 23:31 ` Jonathan Corbet
2010-08-25 23:31 ` Jonathan Corbet
2010-08-25 23:31 ` Jonathan Corbet
2010-08-26 1:38 ` Pawel Osciak
2010-08-26 1:38 ` Pawel Osciak
2010-08-26 1:38 ` Pawel Osciak
2010-08-26 1:49 ` Michał Nazarewicz
2010-08-26 1:49 ` Michał Nazarewicz
2010-08-26 1:49 ` Michał Nazarewicz
2010-08-26 2:49 ` Minchan Kim
2010-08-26 2:49 ` Minchan Kim
2010-08-26 2:49 ` Minchan Kim
2010-08-26 3:04 ` Minchan Kim
2010-08-26 3:04 ` Minchan Kim
2010-08-26 3:04 ` Minchan Kim
2010-08-26 8:20 ` Peter Zijlstra
2010-08-26 8:20 ` Peter Zijlstra
2010-08-26 8:20 ` Peter Zijlstra
2010-08-26 9:29 ` Minchan Kim
2010-08-26 9:29 ` Minchan Kim
2010-08-26 9:29 ` Minchan Kim
2010-08-26 10:06 ` Peter Zijlstra
2010-08-26 10:06 ` Peter Zijlstra
2010-08-26 10:06 ` Peter Zijlstra
2010-08-26 10:21 ` Minchan Kim
2010-08-26 10:21 ` Minchan Kim
2010-08-26 10:21 ` Minchan Kim
2010-08-26 11:05 ` Peter Zijlstra
2010-08-26 11:05 ` Peter Zijlstra
2010-08-26 11:05 ` Peter Zijlstra
2010-08-26 0:58 ` KAMEZAWA Hiroyuki
2010-08-26 0:58 ` KAMEZAWA Hiroyuki
2010-08-26 0:58 ` KAMEZAWA Hiroyuki
2010-08-26 2:12 ` Michał Nazarewicz
2010-08-26 2:12 ` Michał Nazarewicz
2010-08-26 2:12 ` Michał Nazarewicz
2010-08-26 2:50 ` KAMEZAWA Hiroyuki
2010-08-26 2:50 ` KAMEZAWA Hiroyuki
2010-08-26 2:50 ` KAMEZAWA Hiroyuki
2010-08-26 3:44 ` KAMEZAWA Hiroyuki
2010-08-26 3:44 ` KAMEZAWA Hiroyuki
2010-08-26 3:44 ` KAMEZAWA Hiroyuki
2010-08-26 4:01 ` Michał Nazarewicz
2010-08-26 4:01 ` Michał Nazarewicz
2010-08-26 4:01 ` Michał Nazarewicz
2010-08-26 4:39 ` KAMEZAWA Hiroyuki
2010-08-26 4:39 ` KAMEZAWA Hiroyuki
2010-08-26 4:39 ` KAMEZAWA Hiroyuki
2010-08-26 5:54 ` Américo Wang
2010-08-26 5:54 ` Américo Wang
2010-08-26 5:54 ` Américo Wang
2010-08-26 4:06 ` Minchan Kim
2010-08-26 4:06 ` Minchan Kim
2010-08-26 4:06 ` Minchan Kim
2010-08-26 4:14 ` Minchan Kim
2010-08-26 4:14 ` Minchan Kim
2010-08-26 4:14 ` Minchan Kim
2010-08-26 4:30 ` KAMEZAWA Hiroyuki
2010-08-26 4:30 ` KAMEZAWA Hiroyuki
2010-08-26 4:30 ` KAMEZAWA Hiroyuki
2010-08-26 9:36 ` Minchan Kim
2010-08-26 9:36 ` Minchan Kim
2010-08-26 9:36 ` Minchan Kim
2010-08-27 8:16 ` KAMEZAWA Hiroyuki
2010-08-27 8:16 ` KAMEZAWA Hiroyuki
2010-08-27 8:16 ` KAMEZAWA Hiroyuki
2010-08-27 8:37 ` Peter Zijlstra
2010-08-27 8:37 ` Peter Zijlstra
2010-08-27 8:37 ` Peter Zijlstra
2010-09-02 8:54 ` KAMEZAWA Hiroyuki
2010-09-02 8:54 ` KAMEZAWA Hiroyuki
2010-09-02 8:54 ` KAMEZAWA Hiroyuki
2010-09-03 10:29 ` KAMEZAWA Hiroyuki
2010-09-03 10:29 ` KAMEZAWA Hiroyuki
2010-09-03 10:29 ` KAMEZAWA Hiroyuki
2010-09-05 15:57 ` Minchan Kim
2010-09-05 15:57 ` Minchan Kim
2010-09-05 15:57 ` Minchan Kim
2010-09-06 0:08 ` KAMEZAWA Hiroyuki
2010-09-06 0:08 ` KAMEZAWA Hiroyuki
2010-09-06 0:08 ` KAMEZAWA Hiroyuki
2010-08-26 1:22 ` Pawel Osciak
2010-08-26 1:22 ` Pawel Osciak
2010-08-26 1:22 ` Pawel Osciak
2010-08-26 2:40 ` Michał Nazarewicz
2010-08-26 2:40 ` Michał Nazarewicz
2010-08-26 2:40 ` Michał Nazarewicz
2010-08-26 8:18 ` Peter Zijlstra
2010-08-26 8:18 ` Peter Zijlstra
2010-08-26 8:18 ` Peter Zijlstra
2010-08-26 10:18 ` Mel Gorman
2010-08-26 10:18 ` Mel Gorman
2010-08-26 10:18 ` Mel Gorman
2010-08-28 13:08 ` Hans Verkuil
2010-08-28 13:08 ` Hans Verkuil
2010-08-28 13:08 ` Hans Verkuil
2010-08-28 13:34 ` Peter Zijlstra
2010-08-28 13:34 ` Peter Zijlstra
2010-08-28 13:34 ` Peter Zijlstra
2010-08-28 13:58 ` Hans Verkuil
2010-08-28 13:58 ` Hans Verkuil
2010-08-28 13:58 ` Hans Verkuil
2010-08-28 14:16 ` Peter Zijlstra [this message]
2010-08-28 14:16 ` Peter Zijlstra
2010-08-28 14:16 ` Peter Zijlstra
2010-08-30 8:27 ` Clemens Ladisch
2010-08-30 8:27 ` Clemens Ladisch
2010-08-30 8:27 ` Clemens Ladisch
2010-08-26 1:28 ` Michał Nazarewicz
2010-08-26 1:28 ` Michał Nazarewicz
2010-08-26 1:28 ` Michał Nazarewicz
2010-08-26 8:17 ` Peter Zijlstra
2010-08-26 8:17 ` Peter Zijlstra
2010-08-26 8:17 ` Peter Zijlstra
2010-08-27 2:41 ` Michał Nazarewicz
2010-08-27 2:41 ` Michał Nazarewicz
2010-08-27 2:41 ` Michał Nazarewicz
2010-08-26 10:12 ` Mel Gorman
2010-08-26 10:12 ` Mel Gorman
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=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.