The Intel Core 3 304 inside the Beelink EQi 304 has an unusual CPU configuration. It has five physical cores, but only one is a Performance core. The other four are Low Power E-cores.
That asymmetry makes CPU scheduling particularly important. The P-core has a much higher maximum frequency and is substantially faster for some single-threaded workloads. With only one P-core available, Linux cannot simply spread demanding applications across several fast cores. It has to decide which workload should get access to the P-core at any particular moment.
Get that decision right and the design makes considerable sense. Background work can occupy the four LP E-cores while more important or suitable work gets the P-core. Get it wrong and a program can end up running on a considerably slower core while less important work occupies the processor’s only P-core.
I previously looked at CPU scheduling in some depth with the MINISFORUM M2 and its Intel Core Ultra 7 356H. That processor presents Linux with three classes of CPU core and a much larger pool of resources.
I’m not going to repeat that investigation here.
The Core 3 304 presents a much simpler question: does Linux make proper use of its one fast CPU core?
One P-core and four LP E-cores
Linux exposes five CPUs on the Core 3 304.
| Linux CPU | Core type | Maximum frequency |
|---|---|---|
| CPU 0 | P-core | 4.5 GHz |
| CPU 1 | LP E-core | 3.3 GHz |
| CPU 2 | LP E-core | 3.3 GHz |
| CPU 3 | LP E-core | 3.3 GHz |
| CPU 4 | LP E-core | 3.3 GHz |
The kernel is clearly aware that this is a hybrid processor. It reports that hybrid CPU capacity scaling is enabled, with Intel’s P-state driver and Hardware P-states also active. Linux therefore has the information it needs to account for the different capabilities of the cores. The interesting question is whether the scheduler uses that information well.
Before looking at scheduling behaviour, I measured a single-threaded OpenSSL SHA-256 workload when explicitly restricted to each CPU. This shows how much performance can be at stake when Linux chooses one type of core over another.
| CPU | Core type | SHA-256 throughput | Relative performance |
|---|---|---|---|
| CPU 0 | P-core | 3,858,765.86 kB/s | 100.00% |
| CPU 1 | LP E-core | 3,049,553.54 kB/s | 79.03% |
| CPU 2 | LP E-core | 3,049,387.45 kB/s | 79.02% |
| CPU 3 | LP E-core | 3,049,636.58 kB/s | 79.03% |
| CPU 4 | LP E-core | 3,049,599.31 kB/s | 79.03% |
The four LP E-cores deliver virtually identical performance. For this workload, the P-core is around 26.5% faster than the average LP E-core.
That makes the scheduling tests much more than an academic exercise.
Next page: Page 2 – Single-Thread Scheduling and Core Performance
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.