Merged back in Linux 6.9 was [1]AMD Preferred Core support for Linux for the concept of "preferred cores" with newer Zen processors that are communicated via ACPI CPPC for select cores able to reach a higher maximum frequency or should otherwise be preferred over other cores on the system in the name of maximizing performance. That was a nice step forward for better handling newer Ryzen processors on Linux and matching functionality that had already been working under Microsoft Windows. Of focus more recently has been working on enabling more dynamic Preferred Core support for where the priority of the preferred cores may change at run-time.

Coming into focus since that original AMD Preferred Core merge has been working out dynamic rankings for a subset of AMD processors that may change their preference at run-time around higher frequency parts or also in the case of Ryzen X3D processors where a subset of the cores may have access to a larger cache. After issues with previous Linux patches for these dynamic rankings were foiled, a new attempt was posted today.

Patches sent out today implement a new approach for updating the asymmetric CPU core preference dynamically on ranking changes and without having to rebuild the scheduler domain hierarchy.

AMD engineer K Prateek Nayak explained with [2]today's patch series :

"A subset of AMD Processors which support Preferred Core rankings can have these rankings change at runtime to bias the load balancing towards CPUs with higher frequency / larger cache.

In the current implementation, the CPU with the highest asym priority - "asym_prefer_cpu" is cached in the sched_group struct when building the sched domain hierarchy.

Previous approach to uncache the "asym_prefer_cpu" and compute it during load balancing was not popular as it not only lost the benefits of caching but also added more overhead in update_sg_lb_stats().

At OSPM'25, Vincent suggested retaining "asym_prefer_cpu" but updating it dynamically when the asym priority changes without needing to rebuild the entire sched domain hierarchy.

Introduce sched_update_asym_prefer_cpu() which traverses the local hierarchy on priority change and recomputes the "asym_prefer_cpu". Since sched_group for !SD_OVERLAP domains are shared by all the CPUs in sched_group_span(sg) (see get_group() in kernel/sched/topology.c), updating the "asym_prefer_cpu" in the groups of the local hierarchy ensures all the CPUs in the group see the updated value."

We'll see if all the upstream Linux kernel developers are in agreement on this new approach and how quickly this code could be buttoned up for reaching an upcoming Linux merge window for this dynamic AMD Preferred Core rankings support.



[1] https://www.phoronix.com/news/Linux-6.9-AMD-P-State-Preferred

[2] https://lore.kernel.org/linux-pm/20250409053446.23367-1-kprateek.nayak@amd.com/