All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: wency@cn.fujitsu.com, linfeng@cn.fujitsu.com, rob@landley.net,
	isimatu.yasuaki@jp.fujitsu.com, laijs@cn.fujitsu.com,
	jiang.liu@huawei.com, kosaki.motohiro@jp.fujitsu.com,
	minchan.kim@gmail.com, mgorman@suse.de, rientjes@google.com,
	yinghai@kernel.org, rusty@rustcorp.com.au,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 0/5] Add movablecore_map boot option.
Date: Mon, 19 Nov 2012 12:53:25 -0800	[thread overview]
Message-ID: <20121119125325.ed1abba0.akpm@linux-foundation.org> (raw)
In-Reply-To: <1353335246-9127-1-git-send-email-tangchen@cn.fujitsu.com>

On Mon, 19 Nov 2012 22:27:21 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> This patchset provide a boot option for user to specify ZONE_MOVABLE memory
> map for each node in the system.
> 
> movablecore_map=nn[KMG]@ss[KMG]
> 
> This option make sure memory range from ss to ss+nn is movable memory.
> 1) If the range is involved in a single node, then from ss to the end of
>    the node will be ZONE_MOVABLE.
> 2) If the range covers two or more nodes, then from ss to the end of
>    the node will be ZONE_MOVABLE, and all the other nodes will only
>    have ZONE_MOVABLE.
> 3) If no range is in the node, then the node will have no ZONE_MOVABLE
>    unless kernelcore or movablecore is specified.
> 4) This option could be specified at most MAX_NUMNODES times.
> 5) If kernelcore or movablecore is also specified, movablecore_map will have
>    higher priority to be satisfied.
> 6) This option has no conflict with memmap option.

This doesn't describe the problem which the patchset solves.  I can
kinda see where it's coming from, but it would be nice to have it all
spelled out, please.

- What is wrong with the kernel as it stands?
- What are the possible ways of solving this?
- Describe the chosen way, explain why it is superior to alternatives

The amount of manual system configuration in this proposal looks quite
high.  Adding kernel boot parameters really is a last resort.  Why was
it unavoidable here?

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: wency@cn.fujitsu.com, linfeng@cn.fujitsu.com, rob@landley.net,
	isimatu.yasuaki@jp.fujitsu.com, laijs@cn.fujitsu.com,
	jiang.liu@huawei.com, kosaki.motohiro@jp.fujitsu.com,
	minchan.kim@gmail.com, mgorman@suse.de, rientjes@google.com,
	yinghai@kernel.org, rusty@rustcorp.com.au,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 0/5] Add movablecore_map boot option.
Date: Mon, 19 Nov 2012 12:53:25 -0800	[thread overview]
Message-ID: <20121119125325.ed1abba0.akpm@linux-foundation.org> (raw)
In-Reply-To: <1353335246-9127-1-git-send-email-tangchen@cn.fujitsu.com>

On Mon, 19 Nov 2012 22:27:21 +0800
Tang Chen <tangchen@cn.fujitsu.com> wrote:

> This patchset provide a boot option for user to specify ZONE_MOVABLE memory
> map for each node in the system.
> 
> movablecore_map=nn[KMG]@ss[KMG]
> 
> This option make sure memory range from ss to ss+nn is movable memory.
> 1) If the range is involved in a single node, then from ss to the end of
>    the node will be ZONE_MOVABLE.
> 2) If the range covers two or more nodes, then from ss to the end of
>    the node will be ZONE_MOVABLE, and all the other nodes will only
>    have ZONE_MOVABLE.
> 3) If no range is in the node, then the node will have no ZONE_MOVABLE
>    unless kernelcore or movablecore is specified.
> 4) This option could be specified at most MAX_NUMNODES times.
> 5) If kernelcore or movablecore is also specified, movablecore_map will have
>    higher priority to be satisfied.
> 6) This option has no conflict with memmap option.

This doesn't describe the problem which the patchset solves.  I can
kinda see where it's coming from, but it would be nice to have it all
spelled out, please.

- What is wrong with the kernel as it stands?
- What are the possible ways of solving this?
- Describe the chosen way, explain why it is superior to alternatives

The amount of manual system configuration in this proposal looks quite
high.  Adding kernel boot parameters really is a last resort.  Why was
it unavoidable here?

  parent reply	other threads:[~2012-11-19 20:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 14:27 [PATCH 0/5] Add movablecore_map boot option Tang Chen
2012-11-19 14:27 ` Tang Chen
2012-11-19 14:27 ` [PATCH 1/5] x86: Get pg_data_t's memory from other node Tang Chen
2012-11-19 14:27   ` Tang Chen
2012-11-21  5:46   ` Yasuaki Ishimatsu
2012-11-21  5:46     ` Yasuaki Ishimatsu
2012-11-21  5:58     ` Tang Chen
2012-11-21  5:58       ` Tang Chen
2012-11-21  6:06       ` Yasuaki Ishimatsu
2012-11-21  6:06         ` Yasuaki Ishimatsu
2012-11-19 14:27 ` [PATCH 2/5] page_alloc: Add movablecore_map boot option Tang Chen
2012-11-19 14:27   ` Tang Chen
2012-11-21  5:44   ` Yasuaki Ishimatsu
2012-11-21  5:44     ` Yasuaki Ishimatsu
2012-11-21  6:00   ` Yasuaki Ishimatsu
2012-11-21  6:00     ` Yasuaki Ishimatsu
2012-11-19 14:27 ` [PATCH 3/5] page_alloc: Sanitize zone_movable_pfn Tang Chen
2012-11-19 14:27   ` Tang Chen
2012-11-19 14:27 ` [PATCH 4/5] page_alloc: Make movablecore_map has higher priority Tang Chen
2012-11-19 14:27   ` Tang Chen
2012-11-19 14:27 ` [PATCH 5/5] page_alloc: Bootmem limit with movablecore_map Tang Chen
2012-11-19 14:27   ` Tang Chen
2012-11-19 20:53 ` Andrew Morton [this message]
2012-11-19 20:53   ` [PATCH 0/5] Add movablecore_map boot option Andrew Morton
2012-11-20  1:29   ` Jiang Liu
2012-11-20  1:29     ` Jiang Liu
2012-11-20 11:07   ` Yasuaki Ishimatsu
2012-11-20 11:07     ` Yasuaki Ishimatsu
2012-11-20 11:25     ` Jaegeuk Hanse
2012-11-20 11:25       ` Jaegeuk Hanse
2012-11-21  0:36       ` Yasuaki Ishimatsu
2012-11-21  0:36         ` Yasuaki Ishimatsu

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=20121119125325.ed1abba0.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linfeng@cn.fujitsu.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    --cc=rob@landley.net \
    --cc=rusty@rustcorp.com.au \
    --cc=tangchen@cn.fujitsu.com \
    --cc=wency@cn.fujitsu.com \
    --cc=yinghai@kernel.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.