lkml.org 
[lkml]   [2010]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2010-12-30 19:43    [W:0.581 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site