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

What happens when every core is busy?

I also wanted to see what happens when all five cores are already occupied and another CPU-intensive application arrives with exactly the same scheduling priority as the existing work.

I started five normal-priority OpenSSL SHA-256 workloads, waited five seconds for them to occupy the processor, and then launched a sixth identical workload. All six processes used SCHED_OTHER with a niceness of 0. I sampled their CPU placement every 0.2 seconds while the sixth workload ran.

Unlike the preceding foreground-versus-background test, the newcomer had no priority advantage. Linux therefore had no reason to give it preferential access to the sole P-core.

That is what I observed. Rather than assigning CPU 0 permanently to one process, Linux redistributed the six workloads across all five CPUs. Every existing worker was seen running on both the P-core and LP E-cores during the test, and the newcomer behaved in the same way.

The newcomer therefore spent around 16% of my sampled intervals on the P-core. It was not promoted onto CPU 0 simply because it arrived later, nor did any existing worker retain exclusive use of the faster core.

CPU time was also distributed reasonably evenly. The newcomer accumulated 51.77 seconds of CPU time during its nominal 60-second run. With six equally weighted CPU-bound processes sharing five cores, perfectly even sharing would provide around 50 seconds of CPU time to each process during that period.

When all six applications had equal priority, the scheduler treated the P-core as a shared resource and moved workloads between the different core types rather than arbitrarily allowing one process to monopolise CPU 0.

What if I force the issue?

Linux’s automatic scheduling handled the Core 3 304’s unusual 1P+4E layout well in these tests, but there is always the option of taking control manually.

For this test I used taskset to pin one OpenSSL SHA-256 workload to CPU 0, while four additional OpenSSL workloads were pinned individually to CPUs 1-4.

This completely removed CPU placement from the scheduler’s control. Each process was restricted to a single CPU for the entire 60-second test.

The result was completely stable. Across all 290 scheduler samples, the P-core workload remained on CPU 0, while the other four workloads remained on their assigned LP E-cores. I recorded no migrations.

The four LP E-cores averaged approximately 2,969,134 kB/s, while the P-core delivered 3,748,649.96 kB/s. For this OpenSSL workload, the P-core was around 26% faster.

The forced P-core workload achieved 3,748,649.96 kB/s. In the earlier foreground-versus-background test, Linux automatically placed the normal-priority workload on CPU 0 and it achieved 3,715,678.36 kB/s despite heavier contention. The two figures differ by less than 1%.

That does not suggest a meaningful advantage from manually managing affinity in normal use. taskset gives complete control when it is required, but the scheduler had already made the important placement decision correctly.

There is also a small package-wide performance effect visible here. With all five cores fully occupied, both the P-core and LP E-cores delivered slightly lower OpenSSL throughput than in the isolated-core tests.

Next page: Page 6 – Conclusions

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: