[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101202002716.GA13693@shaohui>
Date: Thu, 2 Dec 2010 08:27:16 +0800
From: Shaohui Zheng <shaohui.zheng@...el.com>
To: "shaohui.zheng@...ux.intel.com" <shaohui.zheng@...ux.intel.com>,
David Rientjes <rientjes@...gle.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, haicheng.li@...ux.intel.com,
lethal@...ux-sh.org, ak@...ux.intel.com,
shaohui.zheng@...ux.intel.com, dave@...ux.vnet.ibm.com,
gregkh@...e.de, Haicheng Li <haicheng.li@...el.com>
Subject: Re: [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface
for memory probe
>
> I doubt either Greg or Dave suggested adding duplicate interfaces for the
> same functionality.
>
> The difference is that we needed to add the add_node interface in a new
> mem_hotplug debugfs directory because it's only useful for debugging
> kernel code and, thus, doesn't really have an appropriate place in sysfs.
> Nobody is going to use add_node unless they lack hotpluggable memory
> sections in their SRAT and want to debug the memory hotplug callers. For
> example, I already wrote all of this node hotplug emulation stuff when I
> wrote the node hotplug support for SLAB.
>
> Memory hotplug, however, does serve a non-debugging function and is
> appropriate in sysfs since this is how people hotplug memory. It's an ABI
> that we can't simply remove without deprecation over a substantial period
> of time and in this case it doesn't seem to have a clear advantage. We
> need not add special emulation support for something that is already
> possible for real systems, so adding a duplicate interface in debugfs is
> inappropriate.
so we should still keep the sysfs memory/probe interface without any modifications,
but for the debugfs mem_hotplug/probe interface, we can add the memory region
to a desired node. It is an extention for the sysfs memory/probe interface, it can
be used for memory hotplug emulation. Do I understand it correctly?
--
Thanks & Regards,
Shaohui
--
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