From: Greg Schaefer <gsgs7878@proton.me>
Subject: Mostly-Inverted CPU-Core ordering
To: "tech@openbsd.org" <tech@openbsd.org>
Date: Mon, 12 Jan 2026 04:13:49 +0000

While debugging another issue, I noticed that amd64/cpu_attach (and others
it appears) reorder the ACPI x2APIC CPU list. In a hybrid world, think that
Intel recommends x2APIC ordering by "CPU power" (P-cores first, E-cores next,
LP-cores last). cpu_info_list contains a static primary (boot-CPU) record
and a linked-list to the remaining application processors. The boot core is
copied to the static allocation, but the remaining cores are head-inserted
(reversed) into the linked-list.

        case CPU_ROLE_AP:
#if defined(MULTIPROCESSOR)
                cpu_intr_init(ci);
                cpu_start_secondary(ci);
                clockqueue_init(&ci->ci_queue);
                sched_init_cpu(ci);
                ncpus++;
                if (ci->ci_flags & CPUF_PRESENT) {
 **                      ci->ci_next = cpu_info_list->ci_next;
 **                      cpu_info_list->ci_next = ci;

Using the example of a hybrid process with 2 P-cores, 2 E-cores and 2 LP-cores,
the resulting ordering is P-Core 0, LP-Core 1, LP-Core 0, E-Core 1, E-core 0,
P-core 0. When NICs setup their interrupt queues (often power-of-two), via
intrmap_create(), they are striped across the cores in that mostly-reversed
order.

Unclear what, if any, performance impact this has, but it can make debugging
interesting. The simple fix is appending to cpu_info_list instead of reverse
head-inserting. Please ignore if a known/non-issue.

Sent with Proton Mail secure email.