All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Li Zhong <zhong@linux.vnet.ibm.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: 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>,
	Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Subject: Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number
Date: Wed, 09 Apr 2014 11:20:28 -0500	[thread overview]
Message-ID: <5345734C.1020905@linux.vnet.ibm.com> (raw)
In-Reply-To: <53445245.3020400@intel.com>

On 04/08/2014 02:47 PM, Dave Hansen wrote:
> On 04/08/2014 11:23 AM, Nathan Fontenot wrote:
>> On 04/08/2014 11:13 AM, Dave Hansen wrote:
>>> On 04/08/2014 01:27 AM, Li Zhong wrote:
>>>> If Dave and others don't have further objections, it seems this small
>>>> userspace incompatibility could be accepted by most of us, and I don't
>>>> need to make a version 2. 
>>>
>>> Let me ask another question then.  What are the units of
>>> phys_index/end_phys_index?  How do we expose those units to userspace?
>>>
>>
>> The documentation for these files just states that the files contain
>> the first and last section id of memory in the memory block for
>> phys_index and end_phys_index respectively.
>>
>> I'm not sure the values have ever been units of anything, at least not
>> that I remember.
> 
> <sigh>
> 
> There are two units.  SECTION_SIZE, which is completely internal to the
> kernel, and block_size_bytes which used to be the same as SECTION_SIZE,
> but is not now.  Which one of those two is phys_index/end_phys_index in,
> and if it is in terms of SECTION_SIZE like this patch proposes, how do
> we tell userspace how large SECTION_SIZE is?
> 
> block_size_bytes is supposed to tell you how large the sections are.  In
> the case where we lumped a bunch of sections together, we also bumped up
> block_size_bytes.  That's why we currently divide the *ACTUAL* section
> number in phys_index/end_phys_index by block_size_bytes.
> 
> That document really needs to be updated to stop referring to sections
> (at least in the descriptions of the user interface).  We can not change
> the units of phys_index/end_phys_index without also changing
> block_size_bytes.
> 

Re-reading the documentation. You're correct, it needs help.

-Nathan


  parent reply	other threads:[~2014-04-09 16:20 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
2014-04-09 16:20           ` Nathan Fontenot [this message]
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=5345734C.1020905@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.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=zhangyanfei@cn.fujitsu.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.