Intel has queued a series of scheduler patches in the tip tree, targeted at the Linux 7.3 merge window, that repair cluster load balancing on hybrid processors. The short version is that cluster scheduling, a 2021 feature meant to spread work across CPU clusters sharing an L2 cache, does the right thing on uniform machines and the wrong thing on chips that mix performance and efficiency cores. Ricardo Neri of Intel has been working the problem, and his testing covers Alder Lake, Lunar Lake and Panther Lake in several SMT configurations. No benchmark numbers have been published yet. We looked at what the scheduler was actually getting wrong and how to check your own topology.
The short answer
Intel engineer Ricardo Neri has queued scheduler patches that fix cluster load balancing on hybrid CPUs. Cluster scheduling spreads tasks across clusters that share an L2 cache, which is the right instinct on uniform machines. On hybrid parts it misfires: misfit tasks correctly reach the performance cores, but the leftover tasks that land on efficiency cores fail to spread evenly across the efficiency core clusters. The fix is queued in tip sched core for the Linux 7.3 merge window and was validated on Alder Lake, Lunar Lake and Panther Lake in several SMT configurations. No benchmark figures have been published, and Neri says he plans to measure on Core Ultra parts during the cycle.
Scheduler patches rarely make interesting reading, and most of them deserve that reputation. This one is worth ten minutes because it is a clean example of a failure mode that keeps recurring in the kernel: two mechanisms that are each correct on their own, written years apart, meeting on hardware that neither of them was designed around.
What cluster scheduling was supposed to do
Modern CPUs do not present a flat list of cores. Cores are grouped, and the grouping that matters here is the cluster: a set of cores that share mid level resources, typically an L2 cache. Linux models this as a scheduler domain, enabled through CONFIG_SCHED_CLUSTER, which was added in 2021.
The policy is simple to state. When the machine is only partly busy, spread runnable tasks across clusters rather than packing them into one. Two tasks in two different clusters each get a full share of L2 capacity and bandwidth. Two tasks in the same cluster share it, and on anything that touches memory with any enthusiasm, that shows up.
The opposite choice, packing, is not wrong in general. It is what you want when power matters more than throughput, because a cluster with nothing running on it can drop into a deeper idle state. Linux picks spreading for partly loaded systems because cache contention usually costs more than the idle residency is worth.
On a uniform machine, where every core has the same peak capacity, that logic holds up.
Where it falls over
Now add asymmetric capacity. An Intel hybrid part has performance cores, generally with SMT, and efficiency cores arranged in clusters. The scheduler has a separate mechanism for this, built around the idea of a misfit task: one whose demand exceeds what a small core can deliver, and which therefore needs to be moved to a big one.
On a partially busy system, one with idle CPUs where the busy ones carry roughly one task each, the intended outcome is a two step story. Misfit tasks go to the performance cores. Everything else runs on the efficiency cores, and with cluster scheduling enabled, those leftovers should be spread evenly across the efficiency core clusters.
Step one works. Step two does not. On several Intel hybrid generations already in the field, and on parts still to come, the remaining tasks fail to distribute across the small core clusters the way the design calls for. They end up concentrated, sharing L2 with each other, while other clusters sit idle next to them. That is precisely the outcome cluster scheduling exists to prevent, arrived at through the interaction of two features that were each written assuming the other was not in play.
Neri's series is queued in the tip tree sched core branch and is expected to merge during the Linux 7.3 window. His testing spans Alder Lake, Lunar Lake and Panther Lake, with SMT enabled and disabled, which is the right matrix for a change of this kind since SMT alters how the sibling level of the topology interacts with everything above it.
What you can measure today
There is nothing to configure and no knob to turn. What you can do, cheaply, is know the topology you are running on, so that a future kernel bump either explains a change you observe or rules itself out.
The cluster masks live in sysfs. On a machine with cluster scheduling compiled in, each CPU exposes its cluster siblings, and comparing that against the core type layout tells you how many small core clusters you actually have. On a laptop class hybrid part you will usually find efficiency cores in groups of four sharing an L2, and performance cores presented as their own group with SMT siblings underneath.
Two things are worth capturing before you upgrade. First, whether CONFIG_SCHED_CLUSTER is set in your running kernel config, because a distribution kernel without it will not be affected by any of this. Second, a baseline of the workload you care about, taken at partial load rather than at saturation. The failure only exists when there is somewhere better for a task to go, so a benchmark that pins every core flat will tell you nothing.
What to expect from it
The plain answer is that nobody knows the magnitude yet, and it would be dishonest to imply otherwise. No numbers accompany the series, and Neri has said he intends to benchmark on Core Ultra hardware during the 7.3 cycle.
What is predictable is the shape. The workloads that sit in the failure window are the ones running several independent, moderately cache hungry threads on a machine that is busy but not full. A build server between peaks. A container host at half capacity. A workstation compiling in the background while someone works in the foreground. Those are common enough situations that a correctness fix here is worth having even if the average gain turns out to be modest.
The workloads that will notice nothing are the two extremes: a single thread on a performance core, and a machine pinned at one hundred percent where there is no spare cluster to spread into.
For anyone who operates fleets of hybrid client hardware or small hybrid servers, the useful posture is to treat this as a correctness fix rather than a performance release. Record your topology now, keep the baseline, and read the benchmark results when they arrive rather than the patch summary.
Sources and further reading
- Linux 7.3 To Better Handle Cluster Load Balancing On Intel Hybrid CPUs, Phoronix, August 8, 2026
- Intel Readies New Linux Patches For Optimized Hybrid CPU Performance, Wccftech
- Enable Cluster Scheduling for x86 Hybrid CPUs, LWN.net
- Hybrid scheduling gets more complicated, LWN.net
- Linux Intel Hybrid Scheduling, Brown and Neri, Linux Plumbers Conference 2022
Frequently asked questions
What is cluster scheduling and why was it added to Linux?
Cluster scheduling is a scheduler domain that sits between the SMT level and the whole package level, and it exists because modern CPUs group cores into clusters that share mid level resources, most often an L2 cache. When the kernel is built with CONFIG_SCHED_CLUSTER, the load balancer knows about that grouping and can decide whether two runnable tasks should sit in the same cluster or in different ones. Added in 2021, the default behaviour is to spread tasks across clusters when the machine is only partly busy, because two tasks in separate clusters each get a full share of L2 capacity and bandwidth instead of fighting over one. Packing tasks into a single cluster is the opposite choice and it is sometimes right, mainly for power, since leaving whole clusters idle lets them drop into deeper idle states. The kernel picks spreading by default for partly loaded systems because cache pressure usually costs more than the idle state savings.
What exactly was broken on hybrid processors?
The failure shows up on a partially busy system, meaning one where some CPUs are idle and the busy ones have roughly one task each. On a machine with asymmetric capacity, the scheduler first has to make sure that misfit tasks, the ones too demanding for a small core, end up on the big cores. That part works. Everything left over is supposed to land on the small cores, and when cluster scheduling is enabled those remaining tasks should be spread evenly among the efficiency core clusters rather than crowded into one. That second half is what breaks. The two mechanisms, asymmetric capacity handling and cluster spreading, were each written with the other absent, and their interaction on a topology that has performance cores with SMT alongside clusters of efficiency cores was never really settled. The result is that on several generations of Intel hybrid parts already shipping, plus upcoming ones, the leftover tasks do not distribute the way the design intends.
Which processors are affected, and do I need to do anything?
Intel hybrid designs, meaning the parts that combine performance cores with efficiency cores in clusters. Ricardo Neri validated the work on Alder Lake, Lunar Lake and Panther Lake across different SMT configurations, and the patch description notes the problem affects several already shipped generations as well as future ones. Nothing is required of you as an operator. This is a kernel side scheduling fix with no tunable to flip and no configuration change to make, and if it merges in the 7.3 window it will reach your machines whenever your distribution ships that kernel. The one thing worth doing is knowing your topology before and after, so that if you do measure a difference you can explain it rather than guess at it. Reading the cluster masks under sysfs takes a few seconds and is described below.
How much of a performance difference should I expect?
Nobody has published a number, and that is the honest answer today. The patches are queued in the tip tree sched core branch rather than merged into mainline, and Neri has said he plans to run benchmarks on Intel Core Ultra hardware during the 7.3 cycle. What you can reason about is the shape of the effect rather than its size. The workloads most likely to notice are the ones that fit the failure conditions: a partly loaded machine running several independent, moderately cache hungry tasks at once, which is a fair description of a build server between peaks, a laptop compiling in the background, or a container host that is not saturated. A machine pinned at full load will see much less, because when every core is busy there is nothing left to spread. If your workload is one thread on a big core, this changes nothing at all.
Why is scheduling on hybrid chips so persistently hard?
Because the scheduler has to satisfy several objectives that genuinely conflict, using information it only partly has. It wants throughput, which argues for spreading work across cache domains. It wants low power, which argues for packing work and letting clusters sleep. It wants low latency for interactive tasks, which argues for keeping them near a fast core. And it has to guess how demanding a task is from its recent history, which is a lagging signal on exactly the workloads that change behaviour fastest. On a uniform machine those tradeoffs are already delicate. Add cores with different peak capacity, some with SMT and some without, grouped in clusters that share cache unevenly, and each mechanism written for the uniform case has to be revisited to check what it now assumes. Hybrid scheduling in Linux has been a multi year sequence of exactly these corrections, and this one continues that pattern rather than ending it.