From: Andy Whitcroft <apw@shadowen.org>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>, Mel Gorman <mel@skynet.ie>,
Linux Memory Management <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
kamezawa.hiroyu@jp.fujitsu.com
Subject: Re: zone movable patches comments
Date: Tue, 10 Jul 2007 11:12:49 +0100 [thread overview]
Message-ID: <46935BA1.90003@shadowen.org> (raw)
In-Reply-To: <20070710182944.83D7.Y-GOTO@jp.fujitsu.com>
Yasunori Goto wrote:
>>> No I really don't see why kernelcore=toosmall is any better than
>>> movable_mem=toobig. And why do you think the admin knows how much
>>> memory is enough to run the kernel, or why should that be the same
>>> between different sized machines? If you have a huge machine, you
>>> need much more addressable kernel memory for the mem_map array
>>> before you even think about anything else.
>>>
>>> Actually, it is more likely that the admin knows exactly how much
>>> memory they need to reserve (eg. for their database's shared
>>> memory segment or to hot unplug or whatever), and in that case
>>> it is much better to be able to specify movable_mem= and just be
>>> given exactly what you asked for and the kernel can be given the
>>> rest.
>
> If hot-unplug is invoked after bootup, then movable_mem will be
> useful to specify removable memory size. It is true.
>
> However, if hot-add is invoked at first after bootup,
> movable_mem is not so useful.
> I think admin expects hot-add memory will be removable zone in many
> case, because he wish the memory for his application rather than
> for kernel.
> But, movable mem can't specify size of hot-add memory in the future.
> I suppose "kernelcore" is desirable for its case.
I would have expected either would interact successfully with
hot-remove/hot-add. It makes sense to the administrator to say "I will
be removing this much memory" movable_mem=N. For the hot-add case I
would have expected a zero sized movable_mem would suffice, the new
memory being added to and expanding the zone as it goes.
I envisioned "kernelcore" and "movable_mem" (that name is nasty btw can
anyone think of a better one) being minimum's. So the expansion of
ZONE_MOVABLE on hot-plug of memory fits that semantically. I think what
I am saying is you really want movable_mem=, another sane use-case.
>>> If somebody is playing with this parameter, they definitely know
>>> what they are doing and they are not just blindly throwing it out
>>> over their cluster because it might be a good idea.
>> It feels very much that there are two usage models. Those who know how
>> much "kernel" memory works for them and want whatever is left usable for
>> their small/huge page workloads, and those who know how much they need
>> for their DB and are happy for the system to have the rest. Both seem
>> like valid use cases, both would have the same underlying implementation
>> a sized ZONE_MOVABLE.
>>
>> How about we have two kernel options "kernelcore=" and "movable=" which
>> would both size ZONE_MOVABLE. Both would be the minimum sizes, so the
>> effective differences would be the rounding to whole pageblocks.
>
> I would like to vote it due to above mentioned. :-)
-apw
--
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:[~2007-07-10 10:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 7:50 zone movable patches comments Nick Piggin
2007-07-09 10:30 ` KAMEZAWA Hiroyuki
2007-07-09 11:04 ` Mel Gorman
2007-07-09 11:44 ` KAMEZAWA Hiroyuki
2007-07-09 12:15 ` Nick Piggin
2007-07-09 13:21 ` Mel Gorman
2007-07-10 7:57 ` Nick Piggin
2007-07-10 9:21 ` Andy Whitcroft
2007-07-10 9:54 ` Yasunori Goto
2007-07-10 10:12 ` Andy Whitcroft [this message]
2007-07-10 9:51 ` Mel Gorman
2007-07-10 10:16 ` Nick Piggin
2007-07-10 10:18 ` Nick Piggin
2007-07-10 13:21 ` Mel Gorman
2007-07-12 12:11 ` Andy Whitcroft
2007-07-10 9:08 ` KAMEZAWA Hiroyuki
2007-07-10 9:48 ` Andy Whitcroft
2007-07-10 11:03 ` KAMEZAWA Hiroyuki
2007-07-09 17:39 ` Christoph Lameter
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=46935BA1.90003@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mel@skynet.ie \
--cc=nickpiggin@yahoo.com.au \
--cc=y-goto@jp.fujitsu.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 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.