How macOS Manages M1 CPU Cores
macOS doesn’t provide direct access to cores, core types, or clusters, at least not in public APIs. Instead, these are normally managed through Grand Central Dispatch using Quality of Service (QoS) settings, which macOS then uses to determine thread management policies.
[…]
macOS itself adopts a strategy where most, if not all, of its background tasks are run at lowest QoS. These include automatic Time Machine backups and Spotlight index maintenance. This also applies to compression and decompression performed by Archive Utility: for example, if you download a copy of Xcode in xip format, decompressing that takes a long time as much of the code is constrained to the E cores, and there’s no way to change that.
[…]
In the original M1 chip, with 4 E cores, QoS 9 threads are run with the core frequency set at about 1000 MHz (1 GHz). What happens in the M1 Pro/Max with its 2 E cores is different: if there’s only one thread, it’s run on the cluster at a frequency of about 1000 MHz, but if there are two or more threads, the frequency is increased to 2064 MHz. This ensures that the E cluster in the M1 Pro/Max delivers at least the performance for background tasks as that in the original M1, at similar power consumption, despite the difference in size of the clusters.
Previously:
- Mac Studio
- M1 Icestorm Performance and Asymmetric M1 Pro Core Management
- Running Background Apps on Efficiency Cores
- QoS and Task Segregation Make M1 Macs Feel Faster
- Faster Xcode Updates
- Beware Default QoS
Update (2022-05-09): Howard Oakley:
In many cases, these appear to demonstrate that running code exclusively on E cores uses more energy, not less.
[…]
This result occurs because Activity Monitor, currently version 10.14 in macOS 12.3.1, doesn’t know the difference between processors with identical cores running at fixed frequency, and Apple’s M1 chips, with two different types of core and variable frequencies for each cluster of cores. Given that it’s now nearly 18 months since Apple started shipping its first M1 Macs, you might think that a little surprising. It’s even worse that Activity Monitor’s errors are discouraging developers from making better use of the cores in M1 chips.
[…]
Until Apple updates the figures returned by Activity Monitor for M1 chips, confounding by core type and frequency makes it not just useless, but actually misleading for comparing CPU % or energy. If you need to assess those, for example when considering whether to let the user change the QoS of threads in your code, the only reliable tool is
powermetrics, which provides details of cluster frequencies and power use, as well as active residency.
I show how you can get accurate estimates of power and energy use, and how the E cores in M1 chips can be far more efficient than the P cores. Today’s compression task required less than a third of the energy when run on the E cores, than on the P cores.
Update (2022-05-26): Howard Oakley:
- In real-life use, E cores are normally managed by macOS to run at frequencies of 600 MHz (idle), 972 MHz (one or few threads) or 2064 MHz (multiple threads), with cluster power up to 621 mW.
- When running macOS tasks, P cores are commonly used only in brief bursts at a wider range of frequencies, with cluster power up to 2,000 mW.
- macOS strategy is to load E cores heavily with system tasks, and spare P cores for user tasks. This ensures the user is unaware of and unaffected by heavy system workloads. It also minimises battery use in notebooks.
