Since the cores have the same microarchitecture and thus nearly identical performance characteristics aside from maximum frequency, the scheduling decisions are far simpler than for the 7950X3D or Intel's heterogeneous parts. It's only slightly more complex than Intel's more recent iterations of Turbo Boost, where 8-10 nominally identical cores have different maximum frequencies and one or two are identified as the fastest cores.

The optimal scheduler behavior is: if a task needs more performance than a Zen 4c core can provide, run it on a full-sized Zen4 core. If it doesn't need that extra performance, run it on a Zen4c core to save power.

A properly authored multi-core workload will balance across the cores even if some of them are slower via things like work-stealing, so while having a "thread director" to move the heaviest workloads onto the fastest cores would be nice, this architecture probably still works out pretty good even if it's less than perfect.

My real concern is about single-threaded workloads. The OS needs to schedule them on the higher-clocked cores. Apparently this has been in Windows for years and Linux 6.9 is getting it.

Not certain if it's related, but the recent p-state changes to the related code for AMD in the Linux scheduler has gotten smarter over the last several releases. It can pinpoint which cores are the fastest out similarly speced cores, based on manufacturing processes and related, and prefer those cores for tasks as they can run just a little bit faster.