Message-ID: <alpine.DEB.2.00.1012301028590.12207@chino.kir.corp.google.com>
Date:	Thu, 30 Dec 2010 10:40:33 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	tglx@...utronix.de, "H. Peter Anvin" <hpa@...or.com>,
	x86@...nel.org, eric.dumazet@...il.com, yinghai@...nel.org,
	brgerst@...il.com, gorcunov@...il.com,
	Pekka Enberg <penberg@...nel.org>, shaohui.zheng@...el.com
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.
--
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