From: Andrew Morton <akpm@linux-foundation.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
minchan.kim@gmail.com, Bob Liu <lliubbo@gmail.com>,
fujita.tomonori@lab.ntt.co.jp, m.nazarewicz@samsung.com,
pawel@osciak.com, andi.kleen@intel.com,
felipe.contreras@gmail.com,
"kosaki.motohiro@jp.fujitsu.com" <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 0/4] big chunk memory allocator v4
Date: Fri, 19 Nov 2010 12:56:53 -0800 [thread overview]
Message-ID: <20101119125653.16dd5452.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101119171033.a8d9dc8f.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 19 Nov 2010 17:10:33 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Hi, this is an updated version.
>
> No major changes from the last one except for page allocation function.
> removed RFC.
>
> Order of patches is
>
> [1/4] move some functions from memory_hotplug.c to page_isolation.c
> [2/4] search physically contiguous range suitable for big chunk alloc.
> [3/4] allocate big chunk memory based on memory hotplug(migration) technique
> [4/4] modify page allocation function.
>
> For what:
>
> I hear there is requirements to allocate a chunk of page which is larger than
> MAX_ORDER. Now, some (embeded) device use a big memory chunk. To use memory,
> they hide some memory range by boot option (mem=) and use hidden memory
> for its own purpose. But this seems a lack of feature in memory management.
>
> This patch adds
> alloc_contig_pages(start, end, nr_pages, gfp_mask)
> to allocate a chunk of page whose length is nr_pages from [start, end)
> phys address. This uses similar logic of memory-unplug, which tries to
> offline [start, end) pages. By this, drivers can allocate 30M or 128M or
> much bigger memory chunk on demand. (I allocated 1G chunk in my test).
>
> But yes, because of fragmentation, this cannot guarantee 100% alloc.
> If alloc_contig_pages() is called in system boot up or movable_zone is used,
> this allocation succeeds at high rate.
So this is an alternatve implementation for the functionality offered
by Michal's "The Contiguous Memory Allocator framework".
> I tested this on x86-64, and it seems to work as expected. But feedback from
> embeded guys are appreciated because I think they are main user of this
> function.
>From where I sit, feedback from the embedded guys is *vital*, because
they are indeed the main users.
Michal, I haven't made a note of all the people who are interested in
and who are potential users of this code. Your patch series has a
billion cc's and is up to version 6. Could I ask that you review and
test this code, and also hunt down other people (probably at other
organisations) who can do likewise for us? Because until we hear from
those people that this work satisfies their needs, we can't really
proceed much further.
Thanks.
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-19 20:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-19 8:10 [PATCH 0/4] big chunk memory allocator v4 KAMEZAWA Hiroyuki
2010-11-19 8:12 ` [PATCH 1/4] alloc_contig_pages() move some functions to page_isolation.c KAMEZAWA Hiroyuki
2010-11-21 15:07 ` Minchan Kim
2010-11-19 8:14 ` [PATCH 2/4] alloc_contig_pages() find appropriate physical memory range KAMEZAWA Hiroyuki
2010-11-21 15:21 ` Minchan Kim
2010-11-22 0:11 ` KAMEZAWA Hiroyuki
2010-11-22 11:20 ` Minchan Kim
2010-11-24 0:15 ` KAMEZAWA Hiroyuki
2010-11-19 8:15 ` [PATCH 3/4] alloc_contig_pages() allocate big chunk memory using migration KAMEZAWA Hiroyuki
2010-11-21 15:25 ` Minchan Kim
2010-11-22 0:13 ` KAMEZAWA Hiroyuki
2010-11-22 11:44 ` Minchan Kim
2010-11-24 0:20 ` KAMEZAWA Hiroyuki
2010-11-19 8:16 ` [PATCH 4/4] alloc_contig_pages() use better allocation function for migration KAMEZAWA Hiroyuki
2010-11-22 12:01 ` Minchan Kim
2010-11-19 20:56 ` Andrew Morton [this message]
2010-11-22 0:04 ` [PATCH 0/4] big chunk memory allocator v4 KAMEZAWA Hiroyuki
2010-11-23 15:46 ` Michał Nazarewicz
2010-11-24 0:36 ` KAMEZAWA Hiroyuki
2010-11-22 0:30 ` Felipe Contreras
2010-11-22 8:59 ` Kleen, Andi
2010-11-23 15:44 ` Michał Nazarewicz
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=20101119125653.16dd5452.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=felipe.contreras@gmail.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lliubbo@gmail.com \
--cc=m.nazarewicz@samsung.com \
--cc=minchan.kim@gmail.com \
--cc=pawel@osciak.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;
as well as URLs for NNTP newsgroup(s).