Cluster aware scheduling has been in Linux since 2021, and on Intel hybrid chips it has been putting work in the wrong place the whole time. Intel engineer Ricardo Neri has patches queued in the tip tree scheduler branch for the Linux 7.3 merge window, which opens on Monday, August 17, 2026. The problem is narrow and real: on a partly busy hybrid system the kernel correctly moves demanding tasks to the P cores, then fails to spread the remaining work evenly across the E core clusters. Alder Lake, Lunar Lake and Panther Lake were all used in testing. If you run Linux on Core Ultra hardware, this is the cycle to watch.
The short answer
Intel engineer Ricardo Neri has patches queued in the tip tree scheduler branch, aimed at the Linux 7.3 merge window that opens Monday, August 17, 2026. They target cluster aware load balancing on hybrid Intel CPUs, where demanding tasks correctly reach the P cores but the remaining work fails to spread evenly across the E core clusters. Testing covered Alder Lake with SMT on and off, plus Lunar Lake and Panther Lake, which have an E core cluster that is not attached to the L3 cache. No published throughput figures accompany the patches.
There is a particular kind of bug that survives for years because nothing crashes and nobody sees an error. Your laptop is simply a bit slower than it should be, in a way you would never think to measure. This is one of those.
What the scheduler gets wrong
Cluster aware scheduling arrived in the kernel in 2021, behind CONFIG_SCHED_CLUSTER. The idea is straightforward: cores are physically grouped, groups share caches and power domains, and the load balancer should know that instead of treating every logical CPU as an anonymous slot.
It was built for uniform server silicon, where every core has roughly the same capacity. Intel's hybrid desktop and laptop parts break that assumption, and Intel's Ricardo Neri has spent months documenting exactly how.
The failure shows up on a partially busy system, which is to say the state your machine is in almost all the time. First, the asymmetric capacity logic works correctly: tasks too heavy for a small core, known in the scheduler as misfit tasks, are routed onto the P cores as intended. What should follow is an even spread of the remaining tasks across the E core clusters. That part does not happen. Some clusters end up carrying a pile of work while others sit comparatively idle.
Nothing fails. You just do not get the parallelism, or the thermal headroom, that spreading the load would have given you.
The chips that were tested
Neri tested on Alder Lake, with SMT both disabled and enabled, because it pairs SMT capable P cores with clusters of E cores and therefore exercises both kinds of grouping at once.
He also tested on Lunar Lake and Panther Lake, which carry a topology detail that makes the problem harder: an E core cluster that is not connected to the L3 cache. Migrating a task into a cluster that shares last level cache with the rest of the machine is cheap. Migrating it into one that does not is a different calculation entirely, and the scheduler needs to know which situation it is in.
That is the same broad theme as cache aware scheduling, which landed in Linux 7.2 for big server processors. Both are the kernel learning that a CPU is a map, not a list.
Checking what your own machine reports
Before deciding whether any of this touches you, it is worth seeing what your kernel currently knows about your topology.
If CONFIG_SCHED_CLUSTER is not set, none of this applies to your kernel at all. If it is set and lscpu -e shows more than one cluster of efficient cores, you are exactly the configuration these patches are about.
What else is queued for 7.3
The scheduler fix is one item in a long list. Also lined up for the merge window: AMD P-State gains dynamic EPP with per core granularity for Zen 6, Intel Nova Lake S graphics support is marked stable, initial Apple M3 Pro, Max and Ultra support arrives in console only form, and there is work on a long standing bottleneck affecting small I/O on PCIe Gen5 NVMe drives. Preparation for Intel Starfire, a Panther Lake derived SoC, is also in the queue, along with AMDGPU DCN 6.0 support.
The Apple M3 line deserves a note for expectation management: console only means the machine boots and gives you a text console, not a usable desktop. It is the first step of a long road, not the arrival.
What we would do
If you administer fleets of Core Ultra laptops or small form factor machines, put 7.3 on the test list rather than waiting for your distribution to pick it up next year. The workloads most likely to show a difference are the ones with several runnable tasks that are not individually heavy: compilation with a moderate job count, container builds, test suites, anything that fills the E cores without saturating the machine.
Measure before and after on your own load, because no published numbers exist and generic benchmarks will not represent your cluster layout. If you do get a clean comparison, the kernel mailing list is a better home for it than a forum post.
And if you have been quietly blaming your hybrid laptop for feeling uneven under moderate load, you may have been right, and the fix has a version number now.
Sources and further reading
- Features Coming For Linux 7.3 From Optimizing Intel Hybrid CPUs To Old AMD Athlon XPs, Phoronix, August 14, 2026
- Linux 7.3 To Better Handle Cluster Load Balancing On Intel Hybrid CPUs, Phoronix
- Intel says Linux cluster scheduling fails on its hybrid CPUs, the fix is queued for 7.3, Hardware Busters, August 2026
- Intel moves to fix hybrid CPU load balancing ahead of Linux 7.3, PBX Science, August 2026
Frequently asked questions
What is cluster aware scheduling, in one paragraph?
Modern CPUs do not present a flat list of identical cores. Cores are grouped into clusters that share a cache level or a power domain, and where a task lands inside that structure changes how fast it runs. Cluster aware scheduling, gated behind CONFIG_SCHED_CLUSTER and in the kernel since 2021, teaches the load balancer about that grouping so it can pack or spread tasks deliberately rather than treating every CPU as interchangeable. It was designed against uniform server silicon, where the assumption that all cores have the same capacity holds. That assumption is exactly what a hybrid desktop or laptop part breaks.
What is actually going wrong today?
According to Ricardo Neri's description of the problem, the failure appears on a partially busy system. The asymmetric capacity logic does its job first: tasks too demanding for a small core, which the scheduler calls misfit tasks, get routed onto the big cores correctly. What should happen next is that the remaining tasks spread evenly across the small core clusters. That even distribution does not happen. Work piles up on some clusters while others sit comparatively idle, which wastes both the parallelism you paid for and the thermal headroom that spreading load would have given you.
Which processors are affected?
Any Intel part that mixes performance cores with efficient cores arranged in clusters, which covers hybrid designs from Alder Lake onward through the current Core Ultra generation. Neri tested on Alder Lake with SMT both disabled and enabled, since it combines SMT capable P cores with clusters of E cores, and on Lunar Lake and Panther Lake, which add a further wrinkle: an E core cluster that is not connected to the L3 cache at all. That last topology is the interesting one, because a cluster off the shared cache has very different placement costs from one sitting on it.
Do we have benchmark numbers for the improvement?
Not published ones, and that is worth stating plainly rather than filling the gap with an estimate. The reporting describes the patches, the topologies they were tested against and the fact that they are queued in the scheduler branch of the tip tree. No before and after throughput figures accompanied the submission coverage. Scheduler placement fixes also resist a single headline number by nature, because the gain depends entirely on how many runnable tasks you have and how they map onto your particular cluster layout. A partly loaded system with several parallel tasks has the most to gain, and an idle or fully saturated one has almost nothing.
When can we actually run this?
The merge window for Linux 7.3 opens on Monday, August 17, 2026. Code sitting in the tip tree scheduler branch at merge window time is on a strong track to land, though queued is not the same as merged until Torvalds pulls it. From there the usual rhythm applies: roughly seven release candidates, then a stable 7.3 toward the end of the year, then whatever delay your distribution adds. If you want it sooner, the rc series is the place, on a test machine rather than on anything that matters.