linux

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/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 - 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.