[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] SMP initialization: detection and enumeration

From: Jessica Clarke
Subject: Re: [PATCH] SMP initialization: detection and enumeration
Date: Thu, 30 Jul 2020 22:16:59 +0100

On 30 Jul 2020, at 22:12, Richard Braun <rbraun@sceen.net> wrote:
> On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
>>> It's physically memory mapped to the local APIC address space, but
>>> because of that, it's also not optimal. All systems I know use a scheme
>>> similar to TLS, i.e. using the fs or gs segment register, to fetch
>>> a per-CPU structure and from it, per-CPU data. This avoids relying on
>>> hardware running at a lower frequency than the CPU.
>> You need to do that anyway if you want any guarantees over _what_ the
>> IDs are (normally you want 0 for the BSP, 1 to N-1 for the APs).
> Not really. You can build a CPU ID table on the BSP, and associate CPU IDs
> with all local APIC IDs discovered, and use that look-up table later
> to obtain a CPU ID from the local APIC ID of the CPU running the code.
> It's just too slow compared to using a segment register.

Well, yes, though you probably don't want to be using a fancy hash
table in such low-level code, so you'd either have an array of 2^16 CPU
IDs which is a bit absurd (or at least _used_ to be, these days it's
not that big) or just do some kind of search. I kind of ruled both out
from the get-go because they're too absurd, especially on other systems
where the APIC ID equivalent is 32-bit or 64-bit and you might have
hundreds of cores' IDs to search through to find your own.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]