The high-level pitch of P cores and E cores seems so elegant, but when it actually comes to scheduling, it gets messy fast. Even in a laptop running off a battery, you can't simply switch to E cores because some short-lived work might be latency-sensitive. You also can't assume long-running work should be on an E core because maybe you're anxious to get that video encoded. Even for lots of small work, different core can have different performance characteristics, and a P core might be more efficient for certain workloads.
Funny enough, Unix already has user-settable priorities, aka "nice level". ACPI gives us an idea how plentiful the power is.
So, when powered by AC power, schedule everything on P cores when possible, schedule processes that eat a lot of CPU on P cores, same for any process with a negative nice value.
When powered by a battery, schedule anything with non-negative nice value on E cores, keep one P core up for real-time tasks, and for nice-below-zero tasks.
These are two extremes, but I suppose that the idea is understandable.
That's not really how nice levels have worked traditionally, and would disallow specifying "run on Performance cores, but yield to other processes quickly".
> So, when powered by AC power, schedule everything on P cores when possible, schedule processes that eat a lot of CPU on P cores, same for any process with a negative nice value.
Even when plugged in, you may have thermal limitations. P cores will chew through your power budget more aggressively than E cores. For latency-sensitive workloads you do want to emphasize the P cores, but when throughput is the goal you'll usually be better off not ignoring the E cores, and not trying to run the P cores at high frequency where they're much less efficient. Intel started adding E cores to consumer chips in large part so they could score better on throughput-oriented multithreaded benchmarks like Cinebench; they're decent at compiling code, too, but you'll still want the P core for the linker.
As a user with a laptop, the last thing I want is the OS to decide for me. I want to tell it myself "this is sensitive, put all your energy into it because I'm five minutes away from pushing that important work and I have seven minutes of battery left" or "this won't work at all if run at less than 2 GHz" vs "I must drag what I'm doing along for as long as I can, save every bit of battery possible. The computer can't know about these cases.
> Apart from some models of Alder Lake, it is now impossible to buy an Intel chip that does not have at least P (Performance) and E (Efficiency) cores.
That bit actually still applies. Intel may have branded the 14100F as Raptor Lake, but it is almost certainly Alder Lake silicon, just a higher speed bin of the 12100F.
The i3-14100F is just one example - Intel still sells numerous non-hybrid models across their lineup including most i3s, Pentiums, Celerons, and many server/workstation Xeons. The documentation's claim about availability is overstated.
How about change that to "Anything with more than 6 cores". Anything with 4 cores only has one speed of core. At 6 cores it more of a mixed bag, some have all the same cores, some have a split of performance and efficient cores. Anything over an i5 will have E cores.
The high-level pitch of P cores and E cores seems so elegant, but when it actually comes to scheduling, it gets messy fast. Even in a laptop running off a battery, you can't simply switch to E cores because some short-lived work might be latency-sensitive. You also can't assume long-running work should be on an E core because maybe you're anxious to get that video encoded. Even for lots of small work, different core can have different performance characteristics, and a P core might be more efficient for certain workloads.
Funny enough, Unix already has user-settable priorities, aka "nice level". ACPI gives us an idea how plentiful the power is.
So, when powered by AC power, schedule everything on P cores when possible, schedule processes that eat a lot of CPU on P cores, same for any process with a negative nice value.
When powered by a battery, schedule anything with non-negative nice value on E cores, keep one P core up for real-time tasks, and for nice-below-zero tasks.
These are two extremes, but I suppose that the idea is understandable.
That's not really how nice levels have worked traditionally, and would disallow specifying "run on Performance cores, but yield to other processes quickly".
> So, when powered by AC power, schedule everything on P cores when possible, schedule processes that eat a lot of CPU on P cores, same for any process with a negative nice value.
Even when plugged in, you may have thermal limitations. P cores will chew through your power budget more aggressively than E cores. For latency-sensitive workloads you do want to emphasize the P cores, but when throughput is the goal you'll usually be better off not ignoring the E cores, and not trying to run the P cores at high frequency where they're much less efficient. Intel started adding E cores to consumer chips in large part so they could score better on throughput-oriented multithreaded benchmarks like Cinebench; they're decent at compiling code, too, but you'll still want the P core for the linker.
1 reply →
>when powered by AC power, schedule everything on P cores when possible
Sometime I feel like that is undesirable. It may make system consume more power, thus more heat output and louder.
1 reply →
As a user with a laptop, the last thing I want is the OS to decide for me. I want to tell it myself "this is sensitive, put all your energy into it because I'm five minutes away from pushing that important work and I have seven minutes of battery left" or "this won't work at all if run at less than 2 GHz" vs "I must drag what I'm doing along for as long as I can, save every bit of battery possible. The computer can't know about these cases.
FWIW, Apple leaves it up to the app developer to specify a quality-of-service for a particular execution context:
https://developer.apple.com/library/archive/documentation/Pe...
I feel like cases 1, 2, and 3 broadly fit into "Battery Saver", "Performance", and "Battery Saver" modes?
Thats one of the reasons I switched back to Linux. I've bought Alder Lake and a couple of RockPro64s that have heterogenous CPU sets.
> Apart from some models of Alder Lake, it is now impossible to buy an Intel chip that does not have at least P (Performance) and E (Efficiency) cores.
Really? I just bought one:
https://www.intel.com/content/www/us/en/products/sku/236786/...
> Apart from some models of Alder Lake
That bit actually still applies. Intel may have branded the 14100F as Raptor Lake, but it is almost certainly Alder Lake silicon, just a higher speed bin of the 12100F.
See https://www.intel.com/content/www/us/en/products/compare.htm... and note how none of them get the higher DRAM frequency support or larger L2 caches characteristic of Raptor Lake silicon.
The i3-14100F is just one example - Intel still sells numerous non-hybrid models across their lineup including most i3s, Pentiums, Celerons, and many server/workstation Xeons. The documentation's claim about availability is overstated.
How about change that to "Anything with more than 6 cores". Anything with 4 cores only has one speed of core. At 6 cores it more of a mixed bag, some have all the same cores, some have a split of performance and efficient cores. Anything over an i5 will have E cores.
Hmm, I think Granite Rapids is all P-Cores and goes up to 86 cores (172 threads):
https://en.wikipedia.org/wiki/Granite_Rapids
2 replies →
There are also Xeons, but it limits an OS to use in data centers.
There are workstation Xeons. Though it seems that mobile Xeons are defunct now.