> Although there’s insufficient evidence here to conclude that all cores within a cluster are run at exactly the same frequency, their frequencies don’t appear

> Although there’s insufficient evidence here to conclude that all cores within a cluster are run at exactly the same frequency, their frequencies don’t appear to differ by much. They do run at the same frequency. There is one hardware register to control the frequency for the whole cluster. Any differences you see are measurement errors in powermetrics; for example, for the P-cores, it has a habit of reporting the requested frequency for a core, which may not be achievable if it is a boost frequency (only available with some cores in deep sleep) or there is throttling involved, and then those metrics are incorrect. Use the cluster frequency metric and ignore the core frequencies; the latter are not useful for anything, it's synthetic data. > The two E cores in an M1 Pro, when at 100% active residency and maximum frequency can outperform a single P core at 100% active residency and maximum frequency, while using one fifth of the power. This varies by workload. I did some basic benchmarking to come up with numbers for this, since the Linux scheduler needs them to efficiently schedule processes. The ballpark is that one E-core has about 70% of the performance of a P-core per MHz. Given that E-cores go up to 2064MHz and P-cores up to 3204MHz, that means that a maxed out E-core can perform at around 45% of a maxed out, full boost P-core (which only works if the other 3 cores are in deep sleep); without boost it's more like 48%. However, for some workloads this is way off - Dhrystone actually gives numbers for E-cores that are a mere 32% of the P-core numbers per MHz, making a maxed out P-core 5 times faster than a maxed out E-core, suggesting that that benchmark gets a huge boost out of the wider dispatch in the P-cores. It seems to be an outlier, though, since I haven't found anything else with that disparity. This is an obsolete branch that I'll have to rewrite, but here's the device tree description for the CPU clusters/cores and frequency/P-state settings for the M1 that I wrote for Asahi Linux: https://github.com/AsahiLinux/linux/commit/6b4a8c07239a4209310c967c432ebf6a5db22152 https://github.com/AsahiLinux/linux/commit/6b4a8c07239a42093... Another fun thing in there, which is replicating macOS behavior, is that when the P-core cluster frequency exceeds 2GHz it makes a change to memory controller power management settings, to increase the time-outs before it goes into lower power modes. This reduces DRAM latency under bursty/sparse load/store patterns, which slightly increases performance for some workloads. You can actually further disable DRAM PM and get even better latencies measurable in synthetic benchmarks (designed to measure this), though I wonder if it'll make any difference in any real world workload at that point; I'll have to test it one day. More random fun stuff: this is a table of the latency of switching between different CPU frequencies, as well as the worst-case pipeline stall during the switch. Better than Intel, at least from the numbers I could find :-) https://mrcn.st/p/Zyok1j0g https://mrcn.st/p/Zyok1j0g - one cool thing you might not know is that it always takes longer to go up in frequency than to go down, because going up implies raising the voltage first and that takes time; going down can happen immediately and the voltage can take its time to drop down to the new minimum to save power. That table also shows that I found that a 24MHz "pstate 0" exists, which is probably a PLL bypass (the external refclock is 24MHz) and quite useless (it is definitely below peak efficiency for the cores, below which it makes no sense to run the CPU, ever), so macOS never uses it, but just a random fun discovery. It might be that the bootloader starts out at this frequency before spinning up the PLLs and configuring the p-state machinery. It does mean these cores are very happy to run at <1% of their rated max clock, which suggests they are either a fully static design or at least have very wide clock tolerance for any dynamic logic parts.