Re: [PATCH] SMP initialization: detection and enumeration

[Almudena Garcia]

> 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.

The maximum number of cpus in xAPIC is 256, not 2^16. My array is indexed by Kernel ID.

My array is refitted to the exact number of cpus after enumerating them, to save space.

El jue., 30 jul. 2020 a las 23:17, Jessica Clarke (<jrtc27@jrtc27.com>) escribió:

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.

Jess