public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	tglx@linutronix.de, hpa@zytor.com, x86@kernel.org,
	eric.dumazet@gmail.com, yinghai@kernel.org
Subject: Re: [PATCH 4/9 UPDATED-1] x86: Initialize 32bit logical apicid mapping early during boot
Date: Thu, 18 Nov 2010 09:48:01 +0100	[thread overview]
Message-ID: <4CE4E841.9020107@kernel.org> (raw)
In-Reply-To: <20101118084257.GF26398@elte.hu>

Hello,

On 11/18/2010 09:42 AM, Ingo Molnar wrote:
> This is a very sensitive area of code that tends to blow up in nasty
> ways. So when we do changes here we want them super-finegrained. If
> you split it up into 30 reasonable patches - no problem at
> all. (here up to 5 would suffice i think)

I'll probably split it to three or four.  That said, I don't really
think it would help bisection.  But, anyways, no problem.

>> Yeah, what they do is ugly.  It gets less uglier after the patchset.
>> I'll see if some of them can be dropped but I don't think putting them
>> inside ifdef'd inline functions necessarily improves things.  It often
>> just makes things more difficult to follow.
> 
> Can we remove them? Or does it make any sense on the 64-bit side?

Those are the parts where 32 and 64 actually differ.  On 64, the
mapping between physical and logical are fixed (at least in the
generic arch code) which isn't true on 32, so it doesn't make much
sense for 64.  For now, I would suggest leaving them ugly.  At least
they're now properly localized after the patchset.

Thanks.

-- 
tejun

  reply	other threads:[~2010-11-18  8:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-11 11:02 [PATCHSET RFC] x86: unify x86_32 and 64 NUMA init paths Tejun Heo
2010-11-11 11:02 ` [PATCH 1/9] x86: Kill unused static boot_cpu_logical_apicid in smpboot.c Tejun Heo
2010-11-11 11:13   ` Pekka Enberg
2010-11-11 11:02 ` [PATCH 2/9] x86: Rename x86_32 MAX_APICID to MAX_LOCAL_APIC Tejun Heo
2010-11-11 11:15   ` Pekka Enberg
2010-11-11 11:02 ` [PATCH 3/9] x86: Make default_send_IPI_mask_sequence/allbutself_logical() 32bit only Tejun Heo
2010-11-11 12:02   ` Pekka Enberg
2010-11-11 16:18   ` Cyrill Gorcunov
2010-11-11 17:34   ` [PATCH UPDATED " Tejun Heo
2010-11-11 17:52     ` Cyrill Gorcunov
2010-11-11 11:02 ` [PATCH 4/9] x86: Initialize 32bit logical apicid mapping early during boot Tejun Heo
2010-11-12  1:54   ` Brian Gerst
2010-11-12  9:38   ` [PATCH UPDATED " Tejun Heo
2010-11-12  9:58     ` Yinghai Lu
2010-11-12 10:22       ` Tejun Heo
2010-11-12 10:33   ` [PATCH 4/9 UPDATED-1] " Tejun Heo
2010-11-18  8:30     ` Ingo Molnar
2010-11-18  8:39       ` Tejun Heo
2010-11-18  8:42         ` Ingo Molnar
2010-11-18  8:48           ` Tejun Heo [this message]
2010-11-18  9:08             ` Ingo Molnar
2010-11-11 11:02 ` [PATCH 5/9] x86: Replace apic->apicid_to_node() with ->numa_cpu_node() Tejun Heo
2010-11-11 11:37   ` Pekka Enberg
2010-11-11 11:02 ` [PATCH 6/9] x86: Unify cpu/apicid <-> NUMA node mapping between 32 and 64bit Tejun Heo
2010-11-11 12:01   ` Pekka Enberg
2010-11-11 11:02 ` [PATCH 7/9] x86: Unify CPU -> " Tejun Heo
2010-11-11 11:02 ` [PATCH 8/9] x86: Unify node_to_cpumask_map handling " Tejun Heo
2010-11-11 12:11   ` Pekka Enberg
2010-11-11 11:02 ` [PATCH 9/9] x86: Unify NUMA initialization " Tejun Heo
2010-11-11 12:09   ` Pekka Enberg
2010-11-12 10:32 ` [PATCH 3.5/9] x86: Use local variable to cache smp_processor_id() in setup_local_APIC() 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=4CE4E841.9020107@kernel.org \
    --to=tj@kernel.org \
    --cc=eric.dumazet@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.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