From: Tejun Heo <tj@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
tglx@linutronix.de, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, eric.dumazet@gmail.com, yinghai@kernel.org,
brgerst@gmail.com, gorcunov@gmail.com,
Pekka Enberg <penberg@kernel.org>,
shaohui.zheng@intel.com
Subject: Re: [PATCH 15/16] x86: Unify node_to_cpumask_map handling between 32 and 64bit
Date: Thu, 30 Dec 2010 15:58:58 +0100 [thread overview]
Message-ID: <20101230145858.GE18831@htj.dyndns.org> (raw)
In-Reply-To: <20101230124800.GD18831@htj.dyndns.org>
Hello, again.
On Thu, Dec 30, 2010 at 01:48:00PM +0100, Tejun Heo wrote:
> On Tue, Dec 28, 2010 at 12:43:24PM -0800, David Rientjes wrote:
> > This has been almost entirely rewritten in x86/numa by c1c3443c ("x86,
> > numa: Fake node-to-cpumask for NUMA emulation") and the pending fix
> > http://marc.info/?l=linux-kernel&m=129340072128297 ("x86, numa: Fix
> > CONFIG_DEBUG_PER_CPU_MAPS without NUMA"). Since this is only moving those
> > functions to numa.c, it should be trivial to fix once based on x86/numa.
>
> 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?
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.
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. 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.
That said, Shaohui is already working on unifying the emulation code,
so I'll just do another quick dirty #ifdef'ing for the affected part.
Thank you.
--
tejun
next prev parent reply other threads:[~2010-12-30 14:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-28 11:48 [PATCHSET REPOST] x86: unify x86_32 and 64 NUMA init paths, take#3 Tejun Heo
2010-12-28 11:48 ` [PATCH 01/16] x86: Kill unused static boot_cpu_logical_apicid in smpboot.c Tejun Heo
2010-12-28 11:48 ` [PATCH 02/16] x86: Rename x86_32 MAX_APICID to MAX_LOCAL_APIC Tejun Heo
2010-12-28 11:48 ` [PATCH 03/16] x86: Make default_send_IPI_mask_sequence/allbutself_logical() 32bit only Tejun Heo
2010-12-28 11:48 ` [PATCH 04/16] x86: Replace cpu_2_logical_apicid[] with early percpu variable Tejun Heo
2010-12-28 11:48 ` [PATCH 05/16] x86: Always use x86_cpu_to_logical_apicid for cpu -> logical apic id Tejun Heo
2010-12-28 11:48 ` [PATCH 06/16] x86: Kill apic->cpu_to_logical_apicid() Tejun Heo
2010-12-28 11:48 ` [PATCH 07/16] x86: Add apic->x86_32_early_logical_apicid() Tejun Heo
2010-12-28 11:48 ` [PATCH 08/16] x86: Implement the default x86_32_early_logical_apicid() Tejun Heo
2010-12-28 11:48 ` [PATCH 09/16] x86: Implement x86_32_early_logical_apicid() for bigsmp_32 Tejun Heo
2010-12-28 11:48 ` [PATCH 10/16] x86: Implement x86_32_early_logical_apicid() for summit_32 Tejun Heo
2010-12-28 11:48 ` [PATCH 11/16] x86: Implement x86_32_early_logical_apicid() for numaq_32 Tejun Heo
2010-12-28 11:48 ` [PATCH 12/16] x86: Replace apic->apicid_to_node() with ->x86_32_numa_cpu_node() Tejun Heo
2010-12-28 11:48 ` [PATCH 13/16] x86: Unify cpu/apicid <-> NUMA node mapping between 32 and 64bit Tejun Heo
2010-12-28 20:35 ` David Rientjes
2010-12-29 10:52 ` Tejun Heo
2010-12-29 19:36 ` H. Peter Anvin
2010-12-29 22:05 ` H. Peter Anvin
2010-12-30 11:33 ` Tejun Heo
2010-12-28 11:48 ` [PATCH 14/16] x86: Unify CPU -> " Tejun Heo
2010-12-28 20:39 ` David Rientjes
2010-12-28 11:48 ` [PATCH 15/16] x86: Unify node_to_cpumask_map handling " Tejun Heo
2010-12-28 20:43 ` David Rientjes
2010-12-30 12:48 ` Tejun Heo
2010-12-30 14:58 ` Tejun Heo [this message]
2010-12-30 18:40 ` David Rientjes
2010-12-31 13:20 ` Tejun Heo
2010-12-31 23:09 ` David Rientjes
2010-12-30 18:43 ` David Rientjes
2010-12-28 11:48 ` [PATCH 16/16] x86: Unify NUMA initialization " Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2011-01-23 13:37 [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#5 Tejun Heo
2011-01-23 13:37 ` [PATCH 15/16] x86: Unify node_to_cpumask_map handling between 32 and 64bit Tejun Heo
2010-12-30 17:49 [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#4 Tejun Heo
2010-12-30 17:49 ` [PATCH 15/16] x86: Unify node_to_cpumask_map handling between 32 and 64bit Tejun Heo
2010-11-27 15:21 [PATCHSET] x86: unify x86_32 and 64 NUMA init paths, take#2 Tejun Heo
2010-11-27 15:22 ` [PATCH 15/16] x86: Unify node_to_cpumask_map handling between 32 and 64bit Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101230145858.GE18831@htj.dyndns.org \
--to=tj@kernel.org \
--cc=brgerst@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shaohui.zheng@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®