Beelink Mini PC

Beelink EQi 304: Can Linux Make Proper Use of Its One Fast CPU Core?

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
IntroductionIntroduction to the series and interrogation of the machine
BenchmarksBenchmarking the Beelink EQi 304 Mini PC
PowerTesting and comparing the power consumption
BIOSThe BIOS, which stands for Basic Input/Output System, plays a crucial role
CoresP-core and LP Efficient-cores examined
NoiseHow quiet is this mini PC?
NPU and LlamaTesting the NPU with Llama models
SchedulingCan Linux use its one fast CPU core efficiently?
Subscribe

Please read our Comment Policy before commenting.

Notify of
guest
0 Comments
Oldest
Newest Most Voted