All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Jan Beulich <JBeulich@novell.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: x86_32_early_logical_apicid() -> one warning per CPU on late-determined BIGSMP systems
Date: Fri, 12 Aug 2011 12:15:56 +0200	[thread overview]
Message-ID: <20110812101556.GM23842@htj.dyndns.org> (raw)
In-Reply-To: <4E43EBDF0200007800050CA7@nat28.tlf.novell.com>

Hello,

On Thu, Aug 11, 2011 at 01:49:03PM +0100, Jan Beulich wrote:
> with generic_processor_info() getting run before generic_bigsmp_probe(),
> the values obtained by the former though apic->x86_32_early_logical_apicid()
> (still pointing to default_x86_32_early_logical_apicid() at that time) and
> stored into early_per_cpu(x86_cpu_to_logical_apicid, cpu) can't possibly
> match the ones obtained by setup_local_APIC() (since only at this point
> apic->x86_32_early_logical_apicid() points to bigsmp_early_logical_apicid()),
> thus causing the warning there to generally trigger on each CPU.

Ooh, okay, bigsmp switches apic pretty late in the init.  Wouldn't it
be better to move that to right after dmi init regardless of this
problem?

> Except for removing the warning, all other possible solutions to this that
> I can think of seem ugly to me (i.e. somehow re-initializing
> x86_cpu_to_logical_apicid for all CPUs), but I wonder why setting up
> x86_cpu_to_logical_apicid needs to be done this early if prior to
> setup_local_APIC() doing it a second time the value can't be used for
> anything anyway (because it could validly be BAD_APICID). If there
> aren't any future plans (honestly, I can't really make much sense of
> commit acb8bc09c6185e4d3d582d0076aaa6a89f19d8c5's comment),
> perhaps x86_32_early_logical_apicid() could get removed again?

Yeah, the future already came and went.  On x86_32, cpu -> numa node
mapping API used to require logical apicid and that's the reason why
logical apicid mapping was needed before processor init so that percpu
area affinity can be set up correctly.  This is also why the
requirement was soft - it only affected percpu memory layout.  The API
is now unified with 64bit and based on cpu number (and physical
apicid).  Please take a look at commit 89e5dc218e "x86: Replace
apic->apicid_to_node() with ->x86_32_numa_cpu_node()".

It's interesting that numaq was the only apic which required logical
apicid to calculate numa node and it can't even do that before SMP
bring up making acquiring logical apic ID early rather pointless -
but, well, it was a necessary transition step as logical apicid was
entangled with the rest of 32bit numa init.  Anyways, it's untangled
now and we no longer need early cpu -> logical apicid mapping.

So, yeah, please go ahead and remove it.

Thanks.

-- 
tejun

  reply	other threads:[~2011-08-12 10:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11 12:49 x86_32_early_logical_apicid() -> one warning per CPU on late-determined BIGSMP systems Jan Beulich
2011-08-12 10:15 ` Tejun Heo [this message]
2011-08-18 11:54   ` Jan Beulich
2011-08-18 11:59     ` 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=20110812101556.GM23842@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=JBeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.