A single demanding thread
I started with the easiest possible scheduling decision.
The system was otherwise idle and I ran a sustained single-threaded OpenSSL workload without setting CPU affinity. Linux therefore had five CPUs available, including an idle P-core.
I recorded where the process actually executed rather than relying on occasional snapshots of its current CPU.
| Measurement | Result |
|---|---|
| Time on P-core | 99.80% |
| Time on LP E-cores | 0.20% |
| CPU migrations | 27 |
Linux gets this straightforward case almost exactly right. OpenSSL initially executed on CPU 3, one of the LP E-cores, but after around 57 ms of execution the scheduler moved it to CPU 0.
From that point the P-core was effectively its home. Across the full run, OpenSSL spent 99.80% of its recorded CPU time on CPU 0 and only 0.20% on the four LP E-cores combined.
The scheduler recorded 27 migrations, but that figure makes the movement sound more significant than it was. Most excursions away from CPU 0 were extremely brief, with the process quickly returning to the P-core.
For a sustained workload that benefits strongly from CPU 0, Linux identified the appropriate core very quickly and gave the process almost exclusive use of it.
The P-core is not always the fastest choice
The higher-frequency P-core is not automatically the best place for every workload. I also tested sysbench’s single-threaded CPU benchmark on each individual core.
| CPU | sysbench events/sec | OpenSSL SHA-256 |
|---|---|---|
| CPU 0 – P-core | 3,317.10 | 3,858,765.86 kB/s |
| CPU 1 – LP E-core | 5,133.26 | 3,049,553.54 kB/s |
| CPU 2 – LP E-core | 5,127.93 | 3,049,387.45 kB/s |
| CPU 3 – LP E-core | 5,128.47 | 3,049,636.58 kB/s |
| CPU 4 – LP E-core | 5,137.99 | 3,049,599.31 kB/s |
OpenSSL clearly favours the P-core, with SHA-256 throughput around 26.5% higher than on the average LP E-core.
sysbench produces the opposite result. Its prime-number workload is around 54.7% faster on the LP E-cores than on the P-core.
That is counter-intuitive given CPU 0’s much higher maximum frequency, but it demonstrates why describing it simply as the “fast core” can be misleading. The best core depends on the workload.
Next page: Page 3 – Foreground versus Background Work
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.