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

The eight-task test

This is the test I find most interesting. The CP8180 has exactly eight Cortex-A720 cores and four Cortex-A520 cores, so I start exactly eight sustained CPU-bound processes and leave Linux completely free to place them wherever it wants.

That gives us an unusually clean scheduler test. There are enough A720 cores to accommodate every CPU-heavy process simultaneously, so there should be no need to use an A520 unless the scheduler decides there is some benefit in doing so. The result is about as clear as it could be.

With eight continuously runnable CPU-heavy processes, all 1,600 samples landed on the eight Cortex-A720 cores. Not one appeared on a Cortex-A520. Linux didn’t merely favour the faster cores either. Each of the eight A720 CPUs accounted for exactly 200 samples:

CPU  0: 200
CPU  1: 200
CPU  6: 200
CPU  7: 200
CPU  8: 200
CPU  9: 200
CPU 10: 200
CPU 11: 200

CPU  2:   0
CPU  3:   0
CPU  4:   0
CPU  5:   0

It is hard to imagine a cleaner demonstration of capacity-aware scheduling. Linux has eight demanding processes and eight high-capacity processors available, so it keeps all of that work away from the four Cortex-A520 cores.

What happens with a ninth task?

I then add one more CPU-bound process. There are now nine CPU-intensive jobs competing for eight A720 cores, so Linux can no longer give every runnable task its own fast processor. This is exactly the point at which one of the A520 cores enters service.

CPU  0: 200
CPU  1: 200
CPU  2:   0
CPU  3: 200
CPU  4:   0
CPU  5:   0
CPU  6: 200
CPU  7: 200
CPU  8: 200
CPU  9: 200
CPU 10: 200
CPU 11: 200

The split is mathematically exact. Eight of the nine processes account for 88.9% of the samples and run on A720 cores, while the ninth accounts for the remaining 11.1% and runs on an A520. Linux does not bring one of the small cores into play until demand has genuinely exceeded the eight faster processors.

All 12 cores busy

Finally, I repeat the test with 12 continuously runnable CPU-bound processes. There is now enough work to keep every processor busy, and the distribution once again reflects the hardware topology exactly:

• 1,600 of 2,400 samples on the eight A720 cores: 66.7%.
• 800 of 2,400 samples on the four A520 cores: 33.3%.

That corresponds to eight of the twelve runnable processes being serviced by A720 cores and four by A520 cores. The individual A720 counts are less tidy in this test because processes can migrate between CPUs, but the aggregate split is what matters. Linux is using all 12 cores because there is now enough runnable work to justify doing so.

Taken together, these results are strong evidence that Linux is handling the CP8180’s heterogeneous layout intelligently. With eight heavy processes it avoids the A520 cores completely. Add a ninth and one A520 joins in. Load the processor with twelve tasks and all twelve cores are used. That is exactly the behaviour I hoped to see.

Next page: Page 5: Explicit CPU Affinity

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: