AMD Engineers Post Linux Patches for Capacity-Aware Scheduling on Hybrid CPUs: Fixing Asymmetric Core Allocation on Handhelds and Mobile APUs

On November 15, 2026, AMD’s open-source Linux kernel engineering team submitted a foundational patch series introducing Capacity Aware Scheduling (CAS) for heterogeneous AMD processors. The update directly targets a persistent architectural deficiency within the `amd-pstate` frequency scaling driver, which has treated all CPU cores as computationally uniform regardless of whether they are high-frequency standard cores or area-dense efficiency cores. For the rapidly expanding ecosystem of Linux-based handheld gaming PCs—spanning devices powered by AMD Phoenix 2, Hawk Point, Strix Point, and forthcoming hybrid APUs—this oversight has created noticeable frame pacing inconsistencies and sub-optimal thermal efficiency. By exposing per-CPU capacity metrics directly to the kernel’s scheduler, AMD is establishing the missing telemetry bridge required for intelligent thread placement across asymmetric x86 silicon. ### The Architectural Blind Spot in AMD P-State Frequency Scaling The fundamental driver behind this patch series lies in how AMD’s heterogeneous processor philosophy diverges from traditional asymmetric designs. When Intel introduced hybrid x86 computing with Alder Lake, it paired performance cores with instruction-restricted efficiency cores lacking AVX-512, mandating a dedicated hardware coprocessor—Intel Thread Director—and extensive kernel topology changes to prevent system faults. AMD took a radically different path: both standard Zen cores (such as Zen 4 and Zen 5) and their compact counterparts (Zen 4c and Zen 5c) share the exact same Instruction Set Architecture (ISA), vector capabilities, and Simultaneous Multi-Threading (SMT) support. A Zen 5c core executes identical instructions as a Zen 5 core, differing primarily in physical die footprint, cache hierarchy, and maximum sustained clock frequencies. While this architectural symmetry simplified instruction compatibility, it created a severe blind spot for the Linux operating system. The `amd-pstate` driver leverages ACPI Collaborative Processor Performance Control (CPPC) to negotiate autonomous frequency scaling with processor firmware, yet it historically never exported per-CPU capacity values (`arch_scale_cpu_capacity`) into the kernel scheduler’s topology domain. Consequently, the Completely Fair Scheduler (CFS) and its modern successor, the Earliest Eligible Virtual Deadline First (EEVDF) scheduler, treated every online core as having identical computational throughput. The scheduler operated under the flawed assumption that a 5.1 GHz Zen 5 core and a thermal-throttled 3.3 GHz Zen 5c core offered interchangeable compute bandwidth, distributing runnable threads indiscriminately across the chip. ### Telemetry Failures and Handheld Gaming Performance Penalties On desktop workstations with abundant power envelopes, blind scheduling often remained masked by raw thermal headroom. However, within the constrained 15W to 30W thermal design power (TDP) envelopes of handheld gaming consoles—such as the ASUS ROG Ally series, Lenovo Legion Go, Ayaneo handhelds, and mobile gaming Linux distributions like SteamOS and Bazzite—this lack of capacity awareness has exacted a measurable performance toll. Modern 3D gaming workloads are notoriously asymmetric: a single primary render thread or DirectX/Vulkan command-submission loop frequently bounds frame delivery, while auxiliary worker threads handle asset streaming, spatial audio processing, physics, and input polling. Under unpatched kernels, the Linux scheduler could arbitrarily migrate a game’s primary latency-sensitive rendering thread onto a compact Zen ‘c’ core. Because compact cores feature smaller per-core L3 cache slices and strictly lower maximum frequency curves, this misplaced thread execution immediately triggered frametime jitter, micro-stutters, and degraded 1% low framerate metrics. Simultaneously, lightweight operating system background daemons—such as background telemetry, package updates, or Discord voice compression—could land on primary Zen performance cores, unnecessarily triggering aggressive frequency ramps, increasing core temperatures, and draining battery life. Without explicit capacity signals, the operating system possessed no heuristic to align thread computational demand with appropriate physical silicon tiers. ### Technical Mechanics of Capacity Aware Scheduling Authored by AMD kernel engineer Vishal Badole, the newly submitted patch series restructures `amd-pstate` to continuously calculate and publish normalized, asymmetric capacity ratings for every physical and logical core. Rather than treating core performance as a static constant, the driver evaluates maximum sustained frequency ceilings alongside hardware-reported CPPC performance capabilities, translating these factors into relative scheduler capacity weights. Once these capacity metrics are published through kernel topology hooks, the Linux EEVDF scheduler gains full dimensional awareness of core heterogeneity. When placing tasks, the scheduler’s load balancer can proactively evaluate whether a thread’s historical CPU utilization and latency requirements necessitate an unconstrained performance core or whether the task can be comfortably absorbed by an energy-efficient compact core without inducing scheduling delays. For developers and system administrators requiring predictable baselines or conducting driver diagnostics, the patch series introduces an explicit kernel command-line boot parameter—`amd_case=disable`—enabling complete deactivation of AMD Capacity Aware Scheduling in favor of legacy uniform scheduling. ### Paving the Way for Multi-Tier Zen 6 APUs and Linux 7.5 The timing of this patch series signals broader strategic preparations within AMD’s client and semi-custom engineering pipelines. While current hybrid APUs such as the Ryzen AI 9 HX 370 (featuring four Zen 5 and eight Zen 5c cores) have already highlighted the necessity of fine-grained scheduling, upcoming silicon architectures are poised to introduce even greater core diversity. Industry roadmaps anticipate next-generation mobile architectures, including Kraken Point and future Zen 6 APUs, incorporating three-tier core topologies that pair standard performance cores with compact compute cores and ultra-low-power low-power island cores. By landing Capacity Aware Scheduling upstream ahead of the upcoming Linux 7.5 kernel merge window, AMD is ensuring that mainstream distributions and dedicated handheld operating systems maintain out-of-the-box scheduler alignment without requiring out-of-tree vendor patches. For Linux gamers and handheld enthusiasts, this upstream integration guarantees that as asymmetric APU hardware proliferates across portable form factors, the open-source kernel can extract maximum battery endurance during lightweight media playback while strictly isolating latency-critical gaming pipelines on top-tier performance silicon. ### Sources & Further Reading - [Phoronix: AMD Posts Linux Patches For Capacity Aware Scheduling On Hybrid CPUs](https://www.phoronix.com/news/AMD-Hybrid-Capacity-Aware-Sched) - [AMD: Ryzen Mobile Processors and Heterogeneous APU Architecture](https://www.amd.com/en/products/processors/laptop/ryzen.html) - [Linux Kernel Documentation: amd-pstate CPU Performance Scaling Driver](https://docs.kernel.org/admin-guide/pm/amd-pstate.html) - [Arch Linux Community: CPU Frequency Scaling and EEVDF Scheduler Topology](https://wiki.archlinux.org/title/CPU_frequency_scaling) ~HandheldPC ~AMD ~Linux ~SteamOS ~Hardware