NVIDIA Linux engineer Andrea Righi posted a fresh scheduler patch series on August 31, 2026, and it continues a thread that started back in March. The problem is specific to NVIDIA Vera, but the shape of it is not. When firmware reports slightly different capacities for CPUs that also have SMT enabled, the kernel turns on an asymmetric capacity code path that was designed for big and little cores and that has no idea what a busy hyperthread is. The March patches taught that path to prefer fully idle cores. This new series goes further, marking one sibling in each core as the preferred landing spot.
The short answer
NVIDIA engineer Andrea Righi posted a second scheduler patch series for NVIDIA Vera. The platform reports small firmware capacity differences between CPUs and also runs SMT, which switches on the kernel's SD_ASYM_CPUCAPACITY paths while leaving them blind to busy hyperthreads. A March series fixed the worst of it by preferring fully idle cores. The new series marks PE0 as the preferred sibling of each Olympus core using SD_ASYM_PACKING and teaches idle selection to respect that priority, selecting an idle core first and then the highest priority sibling inside it. The code touched is shared, so the fix reaches any platform with the same combination of flags.
Scheduler bugs rarely look like bugs. Nothing crashes, no log line appears, and every CPU reports itself as busy. The workload simply takes twice as long as the hardware says it should, and someone spends a week proving it is not the application's fault.
That is roughly the story behind the patch series NVIDIA's Andrea Righi posted on August 31, 2026, and behind the earlier one from March that it builds on. The platform in question is NVIDIA Vera and it is not shipping yet, but the mechanism is worth understanding by anyone who runs SMT on anything.
Two kernel features that were never designed to meet
The kernel has a flag, SD_ASYM_CPUCAPACITY, that it sets when the CPUs in a scheduling domain do not all have the same capacity. It exists for the big and little arrangement common in mobile silicon, where some cores are genuinely, structurally faster than others and the scheduler needs to place latency sensitive work on the fast ones.
The kernel also has SMT, where two logical CPUs share one physical core and therefore share its execution resources.
On Vera, both are active at once. The firmware exposes minor frequency variations as capacity differences, which is enough to set the asymmetric capacity flag, and SMT is enabled. Now the asymmetric capacity idle selection logic is running on a topology it was never written for, and it makes a specific mistake: it reads the nominal capacity of a logical CPU and treats it as available compute, without checking whether the sibling sharing that physical core is already saturated.
The result is a scheduler that will place a task on the free half of a busy core while an entirely idle core sits next to it. NVIDIA measured the cost of that at up to roughly 2x on CPU intensive workloads.
March: stop making the wrong choice
The first series, posted in late March 2026, was corrective. It added SMT awareness to the asymmetric capacity paths, with the rule stated plainly: prefer fully idle cores, and do not treat partially idle SMT siblings as full capacity targets where doing so would mislead load balancing.
That rule is not new to the kernel. Ordinary symmetric SMT scheduling has known it for years, which is what makes the bug a little embarrassing and also very ordinary. Two subsystems each behaved correctly in isolation, and the combination fell into a gap neither owned.
NVIDIA's engineers evaluated the alternatives before writing that patch, and the reasoning is worth repeating because it applies to a lot of platform quirks. They could have equalised the CPU capacities in firmware, which would have made the flag stop firing. They could have normalised capacities in the kernel, which would have done the same thing more centrally. They could have enabled asymmetric packing instead. They concluded that teaching the existing path about SMT gave better results than any of the workarounds, which is the harder and more durable answer.
August: start making the right one
The new series is not another fix for the same hole. It expresses a preference that did not exist before.
It makes PE0 the preferred sibling of an Olympus core, using SD_ASYM_PACKING, the mechanism the kernel already uses to say that some CPUs should be filled before others. Then it teaches the fair scheduler's idle selection paths to honour that asymmetric SMT priority.
The resulting order of operations is two stage and worth stating explicitly, because it is the part that makes the design clean. The scheduler first selects an idle core according to its existing placement and capacity rules, unchanged. Only then, having chosen a core, does it pick the highest priority available sibling within it. Core selection and sibling selection stay separate concerns, which is why this composes with the March work rather than replacing it.
Why one sibling should be preferred over the other on a physical core is a hardware detail specific to Olympus, and NVIDIA is the party that knows it. What the kernel needed was a way to be told, and SD_ASYM_PACKING is that way.
The part that applies to hardware you own
Vera is not something you can buy, so the immediate relevance is limited. Two things generalise.
The first is that this patch touches shared fair scheduler code. The asymmetric capacity and idle selection paths are not vendor specific, so once this lands, every platform that sets the same flags inherits the new behaviour. If you run a heterogeneous CPU topology with SMT enabled, you are in that set whether or not you have ever heard of Olympus cores.
The second is the failure mode itself, and it is the one to remember. A firmware table reporting slightly different capacities for CPUs silently switched on an entire body of scheduling logic intended for a different kind of machine. Nothing announced that. There is no boot message saying that asymmetric capacity scheduling is now in play. You find out by benchmarking, noticing a number that is wrong by a factor of two, and reading scheduler source.
If you are chasing performance that does not match the hardware on any SMT system, /sys/kernel/debug/sched/domains will tell you which flags your domains actually have, and that is a faster path to the answer than profiling the application again.
For the wider context on this hardware, our coverage of the Vera Rubin platform and what landed in the Linux 7.3 merge window both touch the same corner of the ecosystem.
Sources and further reading
- NVIDIA Posts Linux Scheduler Patches To Further Boost SMT Performance On NVIDIA Vera, Phoronix, August 31, 2026
- Linux Patches Posted To Fix ~2x Performance Drop For CPU Workloads On NVIDIA Vera Rubin, Phoronix, March 26, 2026
- PATCH v2 0/2 sched/fair: SMT-aware asymmetric CPU capacity, LKML
- Hot Chips 2026: Nvidia breaks down 88-core Vera CPU, Tom's Hardware
Frequently asked questions
What is the actual bug being fixed?
Nominal per logical CPU capacity overstates real compute when the other SMT sibling on the same physical core is busy, because the core does not deliver its full nominal capacity to two threads at once. The kernel's asymmetric capacity paths, gated by SD_ASYM_CPUCAPACITY, were written for platforms where capacity differences come from different core types, not from contention. They therefore treat a partially idle SMT sibling as a full capacity destination and will happily place a task there while a completely idle core sits unused. On NVIDIA's platform, that mistake cost up to roughly 2x on CPU intensive workloads before the March fix.
Why does an asymmetric capacity path fire on a server CPU at all?
Because the firmware exposes small differences in CPU capacity, and the kernel does not distinguish between a small difference and a large one. It sees non uniform capacities, sets SD_ASYM_CPUCAPACITY, and enables scheduling logic that was built for the big and little arrangement found in mobile silicon. Add SMT on top and you get a combination the code was never written against: both asymmetric capacity and hyperthreading active at the same time. NVIDIA's engineers considered other approaches, including normalising the capacities in firmware or in the kernel, and concluded that adding SMT awareness to the existing path produced better results.
What does the new patch series add on top of the March work?
The March series was defensive, it stopped the scheduler from treating half busy cores as good targets and made it prefer fully idle ones. The new series expresses a positive preference instead. It marks PE0 as the preferred sibling of an Olympus core through SD_ASYM_PACKING, the same mechanism used elsewhere in the kernel to express that some CPUs should be filled before others, and teaches the fair scheduler idle selection paths to honour that asymmetric SMT priority. The order is two stage: pick an idle core using existing placement and capacity rules, then pick the highest priority available sibling inside it.
Does any of this affect machines I can actually buy today?
The specific platform is NVIDIA Vera, which is not publicly available yet, so the direct answer is no. The indirect answer is more interesting. These changes touch shared fair scheduler code in the asymmetric capacity and idle selection paths, so once merged they apply to every platform that trips the same flags. Anyone running heterogeneous CPU topologies with SMT enabled is in the affected set, and the class of bug involved, a firmware reported capacity difference silently switching on scheduling behaviour designed for something else, is not unique to one vendor.
What is NVIDIA Vera?
It is NVIDIA's Arm server CPU, detailed at Hot Chips 2026, built around 88 Olympus cores with spatial multithreading and paired with SOCAMM2 memory rated at 1.2 TB per second. It is the CPU half of the Vera Rubin platform, intended to sit next to Rubin GPUs in AI datacentre racks. That context explains the urgency behind the scheduler work: a 2x regression on CPU bound tasks is unpleasant on a workstation and unacceptable on hardware being deployed by the rack to feed accelerators that must not go idle.