Some threads are set to run in the background, and get allocated to the E cores. Could you run them in a VM, and effectively promote them to run on P cores instead?
QoS
Virtual CPU cores are of one type, and QoS has no effect in virtualised macOS. This has consequences for both the host and guest macOS.
Many apps could benefit users of Apple silicon Macs by giving them controls over core use by their threads. Here’s how that can be done simply and effectively.
How you can use the taskpolicy command to confine all the threads of a process to the E cores, as a brake, but there’s no accelerator in macOS.
How can the two E cores in an M1 Pro or Max equal performance of the four in the original M1? Why does running two threads complete in half the time taken to run one?
Threads, GCD and core allocation in Apple silicon explained. How thread priority is baked into code, and how important it is to performance.
It’s a strange coincidence that Intel and Microsoft came up with similar hardware of P and E core types in a SoC, and identical terminology for thread allocation using QoS.
Both P and E cores are run at different frequencies according to the load on M1 chips. This explores how macOS manages their frequencies and why.
How the E and P cores in an M1 Max chip cope with the heavy system workload after login, but still give the user the scope to run apps immediately.
If apps control the Quality of Service, which sets how macOS allocates them to different processor cores in an M1 chip, how can we have any control?
The Eclectic Light Company 