One CPU-heavy task
Next I remove CPU affinity altogether and start a continuously runnable single-threaded workload, repeatedly recording which processor Linux chooses to run it on. There are four Cortex-A520 cores available and Linux is perfectly entitled to use one for light work, but a sustained CPU-bound process is exactly the sort of workload that should benefit from one of the fastest cores.
The result is very clear:
CPU 0: 9 samples CPU 1: 191 samples CPU 2: 0 samples CPU 3: 0 samples CPU 4: 0 samples CPU 5: 0 samples CPU 6: 0 samples CPU 7: 0 samples CPU 8: 0 samples CPU 9: 0 samples CPU 10: 0 samples CPU 11: 0 samples
All 200 samples were on CPUs 0 and 1, the fastest 2.6 GHz Cortex-A720 pair. The process never moved to the 2.5 GHz, 2.3 GHz or 2.2 GHz A720 cores, and none of the four A520 cores received a single sample.
| CPU group | Samples | Share |
|---|---|---|
| CPUs 0-1, 2.6 GHz A720 | 200 | 100.0% |
| CPUs 10-11, 2.5 GHz A720 | 0 | 0.0% |
| CPUs 6-7, 2.3 GHz A720 | 0 | 0.0% |
| CPUs 8-9, 2.2 GHz A720 | 0 | 0.0% |
| CPUs 2-5, 1.8 GHz A520 | 0 | 0.0% |
This is exactly the behaviour I wanted to see. Earlier tests established that the kernel knows the relative capacity of the different CPU groups and that those figures closely match measured performance across the eight Cortex-A720 cores. Here we can see the scheduler putting that information into practice.
For a single sustained CPU-bound workload, Linux selects the fastest available tier and keeps the task there. The process did move between CPU 0 and CPU 1, but that has no practical significance because the two cores have the same maximum frequency, the same CPPC highest_perf value and the same scheduler capacity.
What matters is that the workload spent no sampled time on any of the ten slower processors. That is a good result, although a single-threaded workload is the easy case. Things become much more interesting once there are enough CPU-heavy processes to occupy all eight Cortex-A720 cores at the same time.
Next page: Page 4: The Eight-Task Test
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:
| Minisforum MS-R1 ARM Mini Workstation | |
|---|---|
| Introduction | Introduction to the series and interrogation of the Mini Workstation |
| Benchmarks | Benchmarking the Minisforum MS-R1 ARM Mini Workstation |
| Power | Testing and comparing the power consumption |
| BIOS | Exploring the BIOS |
| Ubuntu | Testing the Ubuntu 26.04 LTS image |
| Scheduling | Minisforum Says Disable Four of the MS-R1’s 12 CPU Cores |

Please read our Comment Policy before commenting.
Hi Steve
Can you point me to where Minisforum say about disabling cores? Is that public info?
Yes, it’s public. Minisforum state the following on their GitHub:
Disable small cores (optimize performance)
Based on current tests, the small cores have much lower performance and internal interconnect bandwidth than the big/medium cores. Running multi-core workloads on the small cores can significantly reduce overall performance. Unless you need the extra cores for virtualization or similar workloads, it is recommended to disable the small cores for normal use.
I really hate ARM processors. Terrible performance, terrible support, terrible value for money.