public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@austin.ibm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Greg KH <gregkh@suse.de>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] memory hotplug disable boot option
Date: Tue, 06 Jul 2010 10:47:48 -0500	[thread overview]
Message-ID: <4C335024.3090609@austin.ibm.com> (raw)
In-Reply-To: <1278430385.8354.23957.camel@nimitz>

On 07/06/2010 10:33 AM, Dave Hansen wrote:
> On Tue, 2010-07-06 at 10:20 -0500, Nathan Fontenot wrote:
>> On 07/01/2010 08:23 AM, Dave Hansen wrote:
>>>
>>> I was thinking more along the lines of just taking adjacent sections and
>>> merging them.  We'll need a new "end address" or size file.  Maybe
>>> "end_phys_index" or something similar.
>>>
>>> Such a beast would not fix all of the pathological cases, like where
>>> only every other 16MB section is populated with RAM, but I don't think
>>> those are very common at all, especially in cases where there's a lot of
>>> RAM.  But, it also has a chance of being relatively backward-compatible.
>>> In most cases, we may even be able to calculate a new phys_block_size
>>> where everything fits evenly and be fully backward-compatible with the
>>> old ABI.
>>
>> Under this scenario were you thinking that all of the memory sections that
>> reside under this memory block would then be acted upon as a whole.  For
>> example would we allow users to hotplug individual memory sections included
>> in th block, or would the memory block be acted upon as a whole?
> 
> I think we would need a mechanism that allowed the sysfs directories to
> be broken down somehow.  If the merging is very successful, it could
> lead to a case where no existing sysfs dir is a reasonable size to
> remove.  That's what we'd have to avoid, so I think we'd _need_
> splitting of some kind.
> 

Agreed.

Perhaps something along the following lines.  We create a sysfs directory
for each memory block, where each memory block can contain multiple memory
sections.  The default being one memory section per memory block.  All of
the existing files that are currently under each memoryXXX directory in sysfs
still appear along with a new file as Dave suggested to indicate the
number of memory sections contained in that memory block.  Additionally,
a new file named 'split' would allow users to split the memory block in
half, thus creating a new directory for the split-off half of the block.

A slight change in the state file behavior would also need to occur, in that
writing 'online' or 'offline' to the file would perform the appropriate
operation on all of the memory sections contained in the memory block.

Thoughts?  I can start working on this if no one has any objections.

-Nathan


  reply	other threads:[~2010-07-06 15:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-25  1:06 [PATCH] memory hotplug disable boot option Nathan Fontenot
2010-06-25  2:04 ` KOSAKI Motohiro
2010-06-25  9:19   ` Andi Kleen
2010-06-25 14:51     ` Nathan Fontenot
2010-06-25 14:56       ` Andi Kleen
2010-06-25 15:21         ` Nathan Fontenot
2010-06-25 15:28           ` Andi Kleen
2010-06-25 16:00             ` Nathan Fontenot
2010-06-28  2:20       ` KOSAKI Motohiro
2010-06-28  4:15         ` Eric W. Biederman
2010-06-28 14:16           ` Andi Kleen
2010-06-28 19:43             ` Eric W. Biederman
2010-06-28 15:02         ` Greg KH
2010-06-28 15:37           ` Nathan Fontenot
2010-06-28 15:44             ` Greg KH
2010-06-29  0:04               ` Dave Hansen
2010-06-29  2:56                 ` KOSAKI Motohiro
2010-06-29 15:38                   ` Nathan Fontenot
2010-06-30  0:00                     ` KOSAKI Motohiro
2010-06-29 16:03                   ` Dave Hansen
2010-06-29 18:04                     ` Greg KH
2010-06-30  0:32                       ` KAMEZAWA Hiroyuki
2010-06-30 15:47                         ` Greg KH
2010-07-01  0:31                           ` KAMEZAWA Hiroyuki
2010-07-01  3:17                             ` Nathan Fontenot
2010-07-01  3:30                               ` KAMEZAWA Hiroyuki
2010-07-01 23:28                                 ` Greg KH
2010-07-01  5:15                             ` KAMEZAWA Hiroyuki
2010-07-01 13:23                             ` Dave Hansen
2010-07-06 15:20                               ` Nathan Fontenot
2010-07-06 15:33                                 ` Dave Hansen
2010-07-06 15:47                                   ` Nathan Fontenot [this message]
2010-07-01 23:26                             ` Greg KH
2010-07-02  5:50                               ` KAMEZAWA Hiroyuki

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=4C335024.3090609@austin.ibm.com \
    --to=nfont@austin.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.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