Messages in this thread | | | Date | Thu, 18 Nov 2010 08:59:11 -0800 | Subject | Re: [7/8,v3] NUMA Hotplug Emulator: extend memory probe interface to support NUMA | From | Aaron Durbin <> |
| |
On Wed, Nov 17, 2010 at 2:44 PM, David Rientjes <rientjes@google.com> wrote: > On Wed, 17 Nov 2010, Dave Hansen wrote: > >> > Then, export the amount of memory that is actually physically present in >> > the e820 but was truncated by mem= >> >> I _think_ that's already effectively done in /sys/firmware/memmap. >> > > Ok. > > It's a little complicated because we don't export each online node's > physical address range so you have to parse the dmesg to find what nodes > were allocated at boot and determine how much physically present memory > you have that's hidden but can be hotplugged using the probe files. > > Adding Aaron Durbin <adurbin@google.com> to the cc because he has a patch > that exports the physical address range of each node in their sysfs > directories.
Is this something that is needed upstream? I can post it if that is the case. Sorry, I don't have a lot of context w.r.t. this thread.
> >> > and allow users to hot-add the memory >> > via the probe interface. Add a writeable 'node' file to offlined memory >> > section directories and allow it to be changed prior to online. >> >> That would work, in theory. But, in practice, we allocate the mem_map[] >> at probe time. So, we've already effectively picked a node at probe. >> That was done because the probe is equivalent to the hardware "add" >> event. Once the hardware where in the address space the memory is, it >> always also knows the node. >> >> But, I guess it also wouldn't be horrible if we just hot-removed and >> hot-added an offline section if someone did write to a node file like >> you're suggesting. It might actually exercise some interesting code >> paths. >> > > Since the pages are offline you should be able to modify the memmap when > the 'node' file is written and use populate_memnodemap() since that file > is only writeable in an offline state. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |