Minisforum Says Disable Four of the MS-R1’s 12 CPU Cores – Is Linux Scheduling Them Properly?

Can Linux match explicit CPU affinity?

So far the scheduler has made all the right decisions. With eight CPU-heavy processes available, Linux fills the eight Cortex-A720 cores and leaves the four Cortex-A520 cores alone. That raises an obvious question: can I improve on that by explicitly restricting the workload to the eight faster cores?

I tested this with an eight-thread sysbench CPU workload. First I allowed Linux to choose freely among all 12 CPUs, then repeated exactly the same test using taskset to restrict sysbench to:

0,1,6,7,8,9,10,11

Those are the eight Cortex-A720 cores.

The unrestricted runs are remarkably consistent, differing by less than six events per second. Left to its own devices, Linux delivers essentially identical performance every time.

The manually restricted figures are much stranger. The first affinity run reaches 8186.73 events per second, effectively identical to the automatic result, but the second falls to 6012.45 and the third reaches only 7117.79. At first sight that looks like thermal throttling or a frequency-scaling problem, but further testing shows that neither is responsible.

One fast core can be left idle

I repeated the affinity test while monitoring the individual sysbench threads, CPU frequencies and temperatures. During a good forced-affinity run, all eight worker threads spread across the eight Cortex-A720 cores. Every A720 was essentially 100% busy and sysbench produced 8183.80 events per second, confirming that there is no inherent performance penalty from restricting the workload to those processors.

The slower runs behaved differently. All sampled work still remained on Cortex-A720 cores, but one of the eight permitted CPUs received no sampled workload at all. In one run CPU 7 was unused. In another it was CPU 8.

The CPUFreq policies remained at their full 2.6 GHz, 2.5 GHz, 2.3 GHz and 2.2 GHz frequencies throughout, while reported temperatures stayed around 40-42 degrees Celsius. The missing core also explains the performance loss surprisingly well. From the earlier single-core tests, CPU 7 delivers about 976 events per second. Remove roughly that amount of performance from an expected total around 8,180 and the result is very close to one of the poor affinity runs.

This is therefore not evidence that manually selecting the A720 cores makes them slower. It looks more like an intermittent scheduling or workload-distribution issue that occurs when this particular eight-thread workload is constrained to that CPU mask. I’m reluctant to call it a kernel bug without much more investigation, but the practical conclusion is straightforward: manually restricting this workload provides no performance advantage and can occasionally make things considerably worse.

The four small cores can still help

The 12-thread result answers another important question. With all 12 CPUs available, the best two runs produce 9866.06 and 9869.77 events per second, around 20.6% more throughput than the eight-thread result.

So the four Cortex-A520 cores are certainly not useless. When there is enough genuinely parallel work to occupy all 12 processors, they add a worthwhile amount of aggregate performance in this benchmark. That fits neatly with the earlier scheduler tests. Linux avoids the A520 cores when eight or fewer heavy tasks are runnable, then brings them into service once the workload grows beyond the eight A720 cores.

For sysbench, at least, that is exactly the behaviour I want. There is little evidence here that disabling the four A520 cores would improve this workload. Linux already keeps eight-thread CPU-heavy work on the A720s automatically while retaining the four smaller cores for jobs that can make productive use of them.

Next page: Page 6: Background Load and Conclusions

Pages in this article:
Page 1: Introduction and CPU Layout
Page 2: Per-Core Performance
Page 3: One CPU-Heavy Task
Page 4: The Eight-Task Test
Page 5: Explicit CPU Affinity
Page 6: Background Load and Conclusions

Complete list of articles in this series: