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 15:34:46 +0200 [thread overview]
Message-ID: <1283002486.1975.3479.camel@laptop> (raw)
In-Reply-To: <201008281508.19756.hverkuil@xs4all.nl>
On Sat, 2010-08-28 at 15:08 +0200, Hans Verkuil wrote:
> > That would be good. Although I expect that the allocation would need
> > to be 100% rock-solid reliable, otherwise the end user has a
> > non-functioning device.
>
> Yes, indeed. And you have to be careful as well how you move pages around.
> Say that you have a capture and an output v4l device: the first one needs
> 64 MB contiguous memory and so it allocates that amount, moving pages around
> as needed. Once allocated that memory is pinned in place since it is needed
> for DMA. So if the output device also needs 64 MB, then you must have a
> guarantee that the first allocation didn't fragment the available contiguous
> memory.
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.
> I also wonder how expensive it is to move all the pages around. E.g. if you
> have a digital camera and want to make a hires picture, then it wouldn't
> do if it takes a second to move all the pages around making room for the
> captured picture. The CPUs in many SoCs are not very powerful compared to
> your average desktop.
Well, that's a trade-off, if you want to have the memory be usable for
anything else (which I understood people did want) then you have to pay
for cleaning it up when you need to use it.
As for the cost of compaction vs regular page-out of random page-cache
memory, compaction is actually cheaper, since it doesn't need to write
out dirty data, and page-out driven writeback sucks due to the
non-linear nature of it.
> And how would memory allocations in specific memory ranges (e.g. memory
> banks) work?
Make sure you reserve pageblocks in the desired range.
> Note also that these issues are not limited to embedded systems, also PCI(e)
> boards can sometimes require massive amounts of DMA-able memory. I have had
> this happen in the past with the ivtv driver with customers that had 15 or so
> capture cards in one box. And I'm sure it will happen in the future as well,
> esp. with upcoming 4k video formats.
I would sincerely hope PCI(e) devices come with an IOMMU (and all memory
lines wired up), really, any hardware that doesn't isn't worth the
silicon its engraved in. Just don't buy it.
next prev parent reply other threads:[~2010-08-28 13:35 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 [this message]
2010-08-28 13:58 ` Hans Verkuil
2010-08-28 14:16 ` Peter Zijlstra
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=1283002486.1975.3479.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