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: <A24AE1FFE7AEC5489F83450EE98351BF28B3BB8C31@shsmsx502.ccr.corp.intel.com>
Date:	Mon, 6 Dec 2010 09:22:54 +0800
From:	"Zheng, Shaohui" <shaohui.zheng@...el.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	Andi Kleen <ak@...ux.intel.com>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Greg KH <gregkh@...e.de>,
	"Li, Haicheng" <haicheng.li@...el.com>,
	"shaohui.zheng@...ux.intel.com" <shaohui.zheng@...ux.intel.com>
Subject: RE: [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface
 for memory probe

After introduce the per-node interface, the following directive can be avoided.

	echo '0x80000000,3' > /sys/kernel/debug/mem_hotplug/add_memory
	echo 'physical_addr=0x80000000 node_id=3' > /sys/kernel/debug/mem_hotplug/add_memory

I already implemented a draft in another thread, and waiting for comments, thanks for the proposal.

Thanks & Regards,
Shaohui


-----Original Message-----
From: David Rientjes [mailto:rientjes@...gle.com] 
Sent: Friday, December 03, 2010 7:34 AM
To: Zheng, Shaohui
Cc: Andrew Morton; linux-mm@...ck.org; linux-kernel@...r.kernel.org; lethal@...ux-sh.org; Andi Kleen; Dave Hansen; Greg KH; Li, Haicheng
Subject: RE: [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface for memory probe

On Thu, 2 Dec 2010, Zheng, Shaohui wrote:

> Why should we add so many interfaces for memory hotplug emulation?

Because they are functionally different from real memory hotplug and we 
want to support different configurations such as mapping memory to a 
different node id or onlining physical nodes that don't exist.

They are in debugfs because the emulation, unlike real memory hotplug, is 
used only for testing and debugging.

> If so, we should create both sysfs and debugfs 
> entries for an online node, we are trying to add redundant code logic.
> 

We do not need sysfs triggers for onlining a node, that already happens 
automatically if the memory that is being onlined has a hotpluggable node 
entry in the SRAT that has an offline node id.

> We need not make a simple thing such complicated, Simple is beautiful, I'd prefer to rename the mem_hotplug/probe 
> interface as mem_hotplug/add_memory.
> 
> 	/sys/kernel/debug/mem_hotplug/add_node (already exists)
> 	/sys/kernel/debug/mem_hotplug/add_memory (rename probe as add_memory)
> 

No, add_memory would then require these bizarre lines that you've been 
parsing like

	echo 'physical_addr=0x80000000 node_id=3' > /sys/kernel/debug/mem_hotplug/add_memory

which is unnecessary if you introduce my proposal for per-node debugfs 
directories similar to that under /sys/devices/system/node that is 
extendable later if we add additional per-node triggers under 
CONFIG_DEBUG_FS.

Adding /sys/kernel/debug/mem_hotplug/node2/add_memory that you write a 
physical address to is a much more robust, simple, and extendable 
interface.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ