From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
tony.luck@intel.com, hpa@zytor.com
Cc: akpm@linux-foundation.org, tangchen@cn.fujitsu.com,
jiang.liu@huawei.com, wujianguo@huawei.com, wency@cn.fujitsu.com,
laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org,
rob@landley.net, minchan.kim@gmail.com, mgorman@suse.de,
rientjes@google.com, guz.fnst@cn.fujitsu.com,
rusty@rustcorp.com.au, lliubbo@gmail.com,
jaegeuk.hanse@gmail.com, glommer@parallels.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v5 0/5] Add movablecore_map boot option
Date: Fri, 18 Jan 2013 15:05:51 +0900 [thread overview]
Message-ID: <50F8E63F.5040401@jp.fujitsu.com> (raw)
In-Reply-To: <50F85ED5.3010003@jp.fujitsu.com>
2013/01/18 5:28, KOSAKI Motohiro wrote:
> On 1/17/2013 11:30 AM, Luck, Tony wrote:
>>> 2. If the user *does* care which nodes are movable, then the user needs
>>> to be able to specify that *in a way that makes sense to the user*.
>>> This may mean involving the DMI information as well as SRAT in order to
>>> get "silk screen" type information out.
>>
>> One reason they might care would be which I/O devices are connected
>> to each node. DMI might be a good way to get an invariant name for the
>> node, but they might also want to specify in terms of what they actually
>> want. E.g. "eth0 and eth4 are a redundant bonded pair of NICs - don't
>> mark both these nodes as removable". Though this is almost certainly not
>> a job for kernel options, but for some user configuration tool that would
>> spit out the DMI names.
>
> I agree DMI parsing should be done in userland if we really need DMI parsing.
>
If users use the boot parameter for bugs or debugging, users need
a method which sets in detail range of movable memory. So specifying
node number is not enough because whole memory becomes movable memory.
For this, we are discussing other ways, memory range and DMI information.
By using DMI information, users may get an invariant name. But is it
really user friendly interface? I don't think so.
You will think using memory range is not user friendly interface too.
But I think that using memory range is friendlier than using DMI
information since we can get easily memory range. So from developper
side, using memory range is good.
Of course, using SRAT information is necessary solution. So we are
developing it now.
Thanks,
Yasuaki Ishimatsu
--
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:[~2013-01-18 6:06 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 9:15 Tang Chen
2013-01-14 9:15 ` [PATCH v5 1/5] x86: get pg_data_t's memory from other node Tang Chen
2013-01-14 9:15 ` [PATCH v5 2/5] page_alloc: add movable_memmap kernel parameter Tang Chen
2013-01-14 22:35 ` Andrew Morton
2013-01-14 9:15 ` [PATCH v5 3/5] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes Tang Chen
2013-01-14 9:15 ` [PATCH v5 4/5] page_alloc: Make movablecore_map has higher priority Tang Chen
2013-01-14 9:15 ` [PATCH v5 5/5] page_alloc: Bootmem limit with movablecore_map Tang Chen
2013-01-14 17:31 ` [PATCH v5 0/5] Add movablecore_map boot option H. Peter Anvin
2013-01-14 22:34 ` Andrew Morton
2013-01-14 22:41 ` Luck, Tony
2013-01-14 22:46 ` Andrew Morton
2013-01-16 6:25 ` Yasuaki Ishimatsu
2013-01-16 21:29 ` Andrew Morton
2013-01-16 22:01 ` KOSAKI Motohiro
2013-01-16 23:00 ` H. Peter Anvin
2013-01-17 20:27 ` KOSAKI Motohiro
2013-01-16 22:52 ` H. Peter Anvin
2013-01-17 1:49 ` Tang Chen
2013-01-17 20:20 ` KOSAKI Motohiro
2013-01-17 5:08 ` Yasuaki Ishimatsu
2013-01-17 6:03 ` H. Peter Anvin
2013-01-17 16:30 ` Luck, Tony
2013-01-17 20:28 ` KOSAKI Motohiro
2013-01-18 6:05 ` Yasuaki Ishimatsu [this message]
2013-01-18 6:25 ` H. Peter Anvin
2013-01-18 7:38 ` Yasuaki Ishimatsu
2013-01-18 8:08 ` Tang Chen
2013-01-18 9:23 ` li guang
2013-01-18 18:29 ` Luck, Tony
2013-01-19 1:06 ` Jiang Liu
2013-01-19 7:52 ` Chen Gong
2013-01-21 7:36 ` Yasuaki Ishimatsu
2013-01-15 1:23 ` Yasuaki Ishimatsu
2013-01-15 3:44 ` H. Peter Anvin
2013-01-15 4:04 ` Luck, Tony
2013-01-15 0:05 ` Toshi Kani
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=50F8E63F.5040401@jp.fujitsu.com \
--to=isimatu.yasuaki@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=hpa@zytor.com \
--cc=jaegeuk.hanse@gmail.com \
--cc=jiang.liu@huawei.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=laijs@cn.fujitsu.com \
--cc=linfeng@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lliubbo@gmail.com \
--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=tony.luck@intel.com \
--cc=wency@cn.fujitsu.com \
--cc=wujianguo@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox