From: Mel Gorman <mel@csn.ul.ie>
To: Micha?? Nazarewicz <m.nazarewicz@samsung.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Daniel Walker <dwalker@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>,
Jonathan Corbet <corbet@lwn.net>,
Pawel Osciak <p.osciak@samsung.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
linux-kernel@vger.kernel.org,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
linux-mm@kvack.org, Kyungmin Park <kyungmin.park@samsung.com>,
Zach Pfeffer <zpfeffer@codeaurora.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
linux-media@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework
Date: Thu, 26 Aug 2010 11:18:55 +0100 [thread overview]
Message-ID: <20100826101855.GF20944@csn.ul.ie> (raw)
In-Reply-To: <op.vh0xp8ix7p4s8u@localhost>
On Thu, Aug 26, 2010 at 04:40:46AM +0200, Micha?? Nazarewicz wrote:
> Hello Andrew,
>
> I think Pawel has replied to most of your comments, so I'll just add my own
> 0.02 KRW. ;)
>
>> Peter Zijlstra <peterz@infradead.org> wrote:
>>> So the idea is to grab a large chunk of memory at boot time and then
>>> later allow some device to use it?
>>>
>>> I'd much rather we'd improve the regular page allocator to be smarter
>>> about this. We recently added a lot of smarts to it like memory
>>> compaction, which allows large gobs of contiguous memory to be freed for
>>> things like huge pages.
>>>
>>> If you want guarantees you can free stuff, why not add constraints to
>>> the page allocation type and only allow MIGRATE_MOVABLE pages inside a
>>> certain region, those pages are easily freed/moved aside to satisfy
>>> large contiguous allocations.
>
> On Thu, 26 Aug 2010 00:58:14 +0200, Andrew Morton <akpm@linux-foundation.org> 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. Could generic core VM provide the required level
>> of service?
>
> I think that the biggest problem is fragmentation here. For instance,
> I think that a situation where there is enough free space but it's
> fragmented so no single contiguous chunk can be allocated is a serious
> problem. However, I would argue that if there's simply no space left,
> a multimedia device could fail and even though it's not desirable, it
> would not be such a big issue in my eyes.
>
For handling fragmentation, there is the option of ZONE_MOVABLE so it's
usable by normal allocations but the CMA can take action to get it
cleared out if necessary. Another option that is trickier but less
disruptive would be to select a range of memory in a normal zone for CMA
and mark it MIGRATE_MOVABLE so that movable pages are allocated from it.
The trickier part is you need to make that bit stick so that non-movable
pages are never allocated from that range. That would be trickish to
implement but possible and it would avoid the fragmentation
problem without pinning memory.
> So, if only movable or discardable pages are allocated in CMA managed
> regions all should work well. When a device needs memory discardable
> pages would get freed and movable moved unless there is no space left
> on the device in which case allocation would fail.
>
> Critical devices (just a hypothetical entities) could have separate
> regions on which only discardable pages can be allocated so that memory
> can always be allocated for them.
>
>> I agree that having two "contiguous memory allocators" floating about
>> on the list is distressing. Are we really all 100% diligently certain
>> that there is no commonality here with Zach's work?
>
> As Pawel said, I think Zach's trying to solve a different problem. No
> matter, as I've said in response to Konrad's message, I have thought
> about unifying Zach's IOMMU and CMA in such a way that devices could
> work on both systems with and without IOMMU if only they would limit
> the usage of the API to some subset which always works.
>
>> Please cc me on future emails on this topic?
>
> Not a problem.
>
> --
> 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>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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-26 10:19 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 [this message]
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
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=20100826101855.GF20944@csn.ul.ie \
--to=mel@csn.ul.ie \
--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=p.osciak@samsung.com \
--cc=peterz@infradead.org \
--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).