Foreground versus background work
A more realistic scheduling challenge is deciding what happens when the processor is already busy with low-priority background work and a normal-priority application suddenly needs CPU time.
For this test I started five OpenSSL SHA-256 workloads at a niceness of 19. With five continuously runnable processes, all five CPU cores were occupied. After five seconds I launched a sixth OpenSSL workload at the normal niceness of 0 and monitored the CPU used by every process at 0.2-second intervals.
This deliberately oversubscribed the processor. The scheduler therefore had to decide whether the newly launched normal-priority task should compete with the background jobs for the LP E-cores or receive preferential access to the single P-core.
The result was unambiguous. The normal-priority process was placed on CPU 0 immediately and remained there for every one of my 292 samples. The five nice-19 background processes were left to share CPUs 1-4.
| Workload | Niceness | SHA-256 throughput |
|---|---|---|
| Normal-priority workload | 0 | 3,715,678.36 kB/s |
| Background 1 | 19 | 2,890,952.52 kB/s |
| Background 2 | 19 | 2,893,111.86 kB/s |
| Background 3 | 19 | 3,150,169.91 kB/s |
| Background 4 | 19 | 2,892,034.75 kB/s |
| Background 5 | 19 | 2,943,285.76 kB/s |
The normal-priority process accumulated 59.35 seconds of CPU time during its nominal 60-second run. Despite six CPU-bound applications competing for five cores, it effectively received a complete CPU to itself.
The background jobs accumulated around 77-79 seconds of CPU time during their 90-second runs. For most of the test, five background workloads were therefore sharing the four LP E-cores while the normal-priority application occupied the P-core.
Background 3 produced somewhat higher throughput than the other low-priority jobs. This likely reflects differences in placement during the initial five-second background-only period and subsequent migration.
This is exactly the behaviour I wanted to see. When a normal-priority CPU-intensive task appeared on an already saturated system, Linux immediately favoured it over the nice-19 background work and gave it exclusive use of the P-core.
Next page: Page 4 – Does Linux Keep the P-core in Reserve?
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 | |
|---|---|
| Introduction | Introduction to the series and interrogation of the machine |
| Benchmarks | Benchmarking the Beelink EQi 304 Mini PC |
| Power | Testing and comparing the power consumption |
| BIOS | The BIOS, which stands for Basic Input/Output System, plays a crucial role |
| Cores | P-core and LP Efficient-cores examined |
| Noise | How quiet is this mini PC? |
| NPU and Llama | Testing the NPU with Llama models |
| Scheduling | Can Linux use its one fast CPU core efficiently? |
Please read our Comment Policy before commenting.