Test 1 – Sustained Single-Thread Scheduling
I’m particularly interested in whether a saturated thread quickly obtains sufficient CPU capacity and whether it subsequently remains relatively stable or moves frequently between CPUs.
The first scheduler experiment is deliberately simple.
I run one sustained CPU-bound process without any CPU affinity restrictions and record where Linux decides to execute it. There is one workload and two monitoring commands. All three run concurrently.
cd ~/m2-scheduler-tests
sudo -v
sudo perf sched record -a \
-o single-thread.data \
-- sleep 70 &
PERF_REC_PID=$!
sudo turbostat --quiet \
--interval 1 \
--num_iterations 70 \
--show 'CPU,Core,Busy%,Avg_MHz,Bzy_MHz,CPU%c1,CPU%c6,CoreTmp,PkgWatt' \
> single-thread-turbostat.txt 2>&1 &
TURBO_REC_PID=$!
sleep 2
openssl speed -seconds 60 -bytes 16384 sha256 \
2>&1 | tee single-thread-workload.txt
wait "$PERF_REC_PID"
wait "$TURBO_REC_PID"This starts both recorders automatically, waits two seconds, runs OpenSSL, and waits for both recorders to finish.
| Measurement | Result |
|---|---|
| Time on P-cores | 59.866 seconds (99.77%) |
| Time on E-cores | 0.135 seconds (0.23%) |
| Time on LP E-cores | 0 seconds (0%) |
| CPU migrations | 1 |
| Predominant core type | P-core |
| Average busy frequency | 4,195 MHz |
| SHA-256 throughput | 3.833 GB/s |
OpenSSL initially ran on CPU 8, an E-core, where it accumulated 135 milliseconds of CPU time. The scheduler then migrated it to CPU 2, a P-core. It remained there for the rest of the benchmark, accumulating 59.866 seconds of P-core execution time without any further migrations.
The workload therefore spent 99.77% of its CPU time on a P-core and never used an LP E-core. Once established on CPU 2, the core averaged 4,195 MHz while busy. SHA-256 throughput reached 3.833 GB/s, only 0.55% below the pinned P-core baseline. The results demonstrate that Linux quickly recognised the sustained workload and moved it from an E-core to the appropriate P-core.
This is probably the simplest demonstration of how CachyOS handles sustained single-thread performance on Panther Lake.
Next page: Page 4 – Bursty Single-Thread Scheduling
Pages in this article:
Page 1 – Introduction
Page 2 – Monitoring CPU Frequency and Activity
Page 3 – Sustained Single-Thread Scheduling
Page 4 – Bursty Single-Thread Scheduling
Page 5 – Scaling from 1 to 16 CPU Workers
Page 6 – Real-World Multithreaded Scheduling with FFmpeg
Page 7 – Foreground Work Against 12 Low-Priority Workers
Page 8 – Foreground Work with All 16 CPUs Busy
Page 9 – Conclusions
Complete list of articles in this series:
| MINISFORUM M2 Core Ultra 7 356H Mini PC | |
|---|---|
| Introduction | Introduction to the series and interrogation of the machine |
| NPU | Setting up and testing the NPU |
| Benchmarks | I run a series of benchmarks focusing on the CPU, GPU, Memory, and Disk performance |
| Power | Testing and comparing the power consumption |
| BIOS | In the world of computing, BIOS, which stands for Basic Input/Output System, plays a crucial role |
| Cores | A look at Intel’s hybrid architecture |
| Intel processors | P-Cores, E-Cores and LP E-Cores Compared Across 4 Intel Processors |
| NPU | NPU and Llama |
| Scheduling | Does Linux Schedule Panther Lake Correctly? |
| Next articles in the series will continue to focus on the machine's NPU | |
Please read our Comment Policy before commenting.