linux-kernel - Re: [PATCH] memory hotplug disable boot option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4C335024.3090609@austin.ibm.com>
Date:	Tue, 06 Jul 2010 10:47:48 -0500
From:	Nathan Fontenot <nfont@...tin.ibm.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
CC:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Greg KH <gregkh@...e.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] memory hotplug disable boot option

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/