From: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Nathan Fontenot <nfont@linux.vnet.ibm.com>,
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>, <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number
Date: Thu, 10 Apr 2014 11:47:57 +0800 [thread overview]
Message-ID: <5346146D.5030801@cn.fujitsu.com> (raw)
In-Reply-To: <1397099672.25199.43.camel@ThinkPad-T5421.cn.ibm.com>
On 04/10/2014 11:14 AM, Li Zhong wrote:
> On Wed, 2014-04-09 at 08:49 -0700, Dave Hansen wrote:
>> On 04/09/2014 02:20 AM, Li Zhong wrote:
>>> Or do you mean we don't need to expose any information related to
>>> SECTION to userspace?
>>
>> Right, we don't need to expose sections themselves to userspace. Do we?
>>
> OK, I agree with that.
>
> Yanfei, I recall you once expressed your preference for section
> numbers?
Hmmm.... Looking at the git log:
commit d33601644cd3b09afb2edd9474517edc441c8fad
Author: Nathan Fontenot <nfont@austin.ibm.com>
Date: Thu Jan 20 10:44:29 2011 -0600
memory hotplug: Update phys_index to [start|end]_section_nr
Update the 'phys_index' property of a the memory_block struct to be
called start_section_nr, and add a end_section_nr property. The
data tracked here is the same but the updated naming is more in line
with what is stored here, namely the first and last section number
that the memory block spans.
The names presented to userspace remain the same, phys_index for
start_section_nr and end_phys_index for end_section_nr, to avoid breaking
anything in userspace.
This also updates the node sysfs code to be aware of the new capability for
a memory block to contain multiple memory sections and be aware of the memory
block structure name changes (start_section_nr). This requires an additional
parameter to unregister_mem_sect_under_nodes so that we know which memory
section of the memory block to unregister.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Reviewed-by: Robin Holt <holt@sgi.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
So obviously, Nathan added the end_phys_index sysfile to present the last section
number of a memory block (for end_section_nr), but what he did in the patch
seems not matching the log.
So what is the motivation of adding this 'end_phys_index' file here?
Confused.
--
Thanks.
Zhang Yanfei
next prev parent reply other threads:[~2014-04-10 3:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 8:56 [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number Li Zhong
2014-04-02 16:09 ` Dave Hansen
2014-04-03 1:50 ` Li Zhong
2014-04-03 22:41 ` KOSAKI Motohiro
2014-04-03 1:37 ` Zhang Yanfei
2014-04-03 2:37 ` Li Zhong
2014-04-03 3:06 ` Zhang Yanfei
2014-04-03 6:45 ` Li Zhong
2014-04-04 1:29 ` Yasuaki Ishimatsu
2014-04-08 8:27 ` Li Zhong
2014-04-08 16:13 ` Dave Hansen
2014-04-08 18:23 ` Nathan Fontenot
2014-04-08 19:47 ` Dave Hansen
2014-04-09 9:20 ` Li Zhong
2014-04-09 15:49 ` Dave Hansen
2014-04-09 16:16 ` Nathan Fontenot
2014-04-10 3:14 ` Li Zhong
2014-04-10 3:47 ` Zhang Yanfei [this message]
2014-04-09 16:20 ` Nathan Fontenot
2014-04-09 17:39 ` Nathan Fontenot
2014-04-10 1:03 ` Zhang Yanfei
2014-04-10 4:17 ` Li Zhong
2014-04-11 18:54 ` Nathan Fontenot
2014-04-14 8:43 ` [RFC PATCH v2] memory-hotplug: Update documentation to hide information about SECTIONS and remove end_phys_index Li Zhong
2014-04-14 9:13 ` Zhang Yanfei
2014-04-15 2:49 ` Li Zhong
2014-04-16 1:49 ` [RFC PATCH v3] " Li Zhong
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=5346146D.5030801@cn.fujitsu.com \
--to=zhangyanfei@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nfont@linux.vnet.ibm.com \
--cc=zhong@linux.vnet.ibm.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.