Does Linux keep the P-core in reserve?
I next looked at what happens when the system has four deliberately low-priority CPU-bound workloads but no normal-priority work competing for processor time.
I started four OpenSSL SHA-256 workloads at a niceness of 19 and sampled their CPU placement every 0.2 seconds for 60 seconds. With four LP E-cores available, Linux could theoretically have placed all four workloads on those cores and left the sole P-core idle.
It did not.
One background worker was placed on CPU 0 and remained there for every one of my 295 samples. Two other workers remained fixed to individual LP E-cores throughout the test. The remaining worker started on CPU 2 and made a single migration to CPU 3.
| Worker | CPU placement | SHA-256 throughput |
|---|---|---|
| Background 1 | CPU 0 – P-core | 3,858,018.84 kB/s |
| Background 2 | CPU 4 – LP E-core | 3,050,047.19 kB/s |
| Background 3 | CPU 2 / CPU 3 – LP E-cores | 3,049,508.52 kB/s |
| Background 4 | CPU 1 – LP E-core | 3,049,717.79 kB/s |
The throughput figures make the distinction between the core types particularly obvious. The process on CPU 0 achieved 3,858,018.84 kB/s, while the three workloads on the LP E-cores all delivered almost exactly 3.05 million kB/s.
These figures are also almost identical to my earlier individually pinned OpenSSL results. Linux was therefore making essentially full use of the performance available from each occupied core.
The important point is that Linux does not keep the sole P-core in reserve simply because all current work has been assigned a low priority. When useful work is available, the scheduler uses the P-core rather than leaving it idle.
Taken together with the preceding test, this is sensible behaviour. Linux uses the P-core to increase throughput when there is no more important work waiting, but a normal-priority workload can take precedence when the processor becomes oversubscribed.
Next page: Page 5 – What Happens When Every Core Is Busy?
Pages in this article:
Page 1 – Introduction and Core Layout
Page 2 – Single-Thread Scheduling and Core Performance
Page 3 – Foreground versus Background Work
Page 4 – Does Linux Keep the P-core in Reserve?
Page 5 – What Happens When Every Core Is Busy?
Page 6 – Conclusions
Complete list of articles in this series:
| Beelink EQi 304 Mini PC | |
|---|---|
| Introduction | Introduction to the series and interrogation of the machine |
| Benchmarks | Benchmarking the Beelink EQi 304 Mini PC |
| Power | Testing and comparing the power consumption |
| BIOS | The BIOS, which stands for Basic Input/Output System, plays a crucial role |
| Cores | P-core and LP Efficient-cores examined |
| Noise | How quiet is this mini PC? |
| NPU and Llama | Testing the NPU with Llama models |
| Scheduling | Can Linux use its one fast CPU core efficiently? |
Please read our Comment Policy before commenting.