Messages in this thread | | | Date | Thu, 30 Dec 2010 10:40:33 -0800 (PST) | From | David Rientjes <> | Subject | Re: [PATCH 15/16] x86: Unify node_to_cpumask_map handling between 32 and 64bit |
| |
On Thu, 30 Dec 2010, Tejun Heo wrote:
> > Sigh, the new NUMA emulation thing is 64bit only. :-( I'll see if it > > can be applied to 32bit too. BTW, how does this interact with the > > Shaohui's patchset. Isn't that about NUMA emulation too? Are these > > the same patches? >
Shaohui's patchset is for node hotplug emulation, not for NUMA emulation which has existed for x86_64 for at least over four years.
> Okay, after going through the changes, here are some thoughts FWIW. > > I'm doubtful the direction was the correct one. NUMA emulation, > almost by definition, doesn't vary too much depending on the > underlying hardware and how it's configured. All that's necessary is > the physical node map an apicid to nid mapping, which can and probably > should be represented in common form regardless of emulation and the > emulation code should simply manipulate the parsed information. >
And pxm mappings since node_distance() must reflect the physical topology on the emulated environment. We have specialized callbacks in the amd and ACPI code to ascertain the physical topology because its discovery is handled differently, either with an implied set of possible nodes in the amd case and the statically-allocated nodes_parsed in the ACPI case, prior to actually onlining the nodes which is suppressed for NUMA emulation.
> The original implementation was 64bit apic specific. If it needed to > be extended to cover amd topology, the right way would be updating the > apic and amd numa code so that they generate the information in a > uniform way and NUMA emulation would follow naturally.
You could export an apicid-to-node and pxm-to-node mapping from both amd and ACPI code to do the actual remap, but it would still require seperate functions, amd_fake_nodes() and acpi_fake_nodes(), to determine what the mapping should be. Instead of adding an additional layer of indirection, it's currently done in a single function depending on whether amd or acpi is being used.
> Instead, it > looks like what happened was simply adding amd specific code with more > gluing. The unnecessary differences between acpi and amd paths sure > aren't your fault but I really don't think we should be moving toward > that direction when things can (and definitely should) be unified with > a bit more effort. NUMA code already is unnecessary hairy with > 32/64bit and different subarchs somewhat unified but subtly differing > in many places without clear indications. >
I agree that unification is in our best interest but the patches as they sit in x86/numa right now actually fix real bugs when using numa=fake on the command line and adding i386 NUMA emulation is an additional feature (and the unification that can be done in the meantime would only be the actual apicid-to-node and pxm-to-node mappings after it is exported from amd and acpi specific functions), so I'd prefer to handle cleanups as incremental patches on top of those.
| |