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: Fri, 31 Dec 2010 14:20:34 +0100 [thread overview]
Message-ID: <20101231132034.GK18831@htj.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1012301028590.12207@chino.kir.corp.google.com>
Hello,
On Thu, Dec 30, 2010 at 10:40:33AM -0800, David Rientjes wrote:
> 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.
I see. Yeah, I should have actually read the patchset before talking
about it.
> 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
I'm not really arguing against you and as said before the patches were
fine given the current state of the code, but I still want to point
out that it's through these mostly innocent series of changes which
build upon existing complications which eventually lead to
unsustainable pile of mess. No one is particularly wrong but then
again none does what really needs to be done.
> (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.
The problem is that those "incremental" patches often don't happen
once the itch is gone while the immediate fixes/improvements aggravate
existing complications. If you were/are planning to clean it up, I
have nothing to whine about. :-)
Thanks.
--
tejun
next prev parent reply other threads:[~2010-12-31 13:20 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
2010-12-30 18:40 ` David Rientjes
2010-12-31 13:20 ` Tejun Heo [this message]
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=20101231132034.GK18831@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;
as well as URLs for NNTP newsgroup(s).