MINISFORUM M2 – Does Linux Schedule Panther Lake Correctly?

Test 5 – Foreground Work Against 12 Low-Priority Workers

The next test examines a situation closer to desktop use.

I start 12 low-priority CPU-intensive workers.

cd ~/m2-scheduler-tests
sudo -v

sudo perf sched record -a \
    -o foreground-load.data \
    -- sleep 75 \
    > foreground-load-perf-record.txt 2>&1 &
FOREGROUND_PERF_PID=$!

sudo turbostat --quiet \
    --interval 1 \
    --num_iterations 75 \
    --show 'CPU,Core,Busy%,Avg_MHz,Bzy_MHz,CPU%c1,CPU%c6,CoreTmp,PkgWatt' \
    > foreground-load-turbostat.txt 2>&1 &
FOREGROUND_TURBO_PID=$!

sleep 2

nice -n 19 stress-ng \
    --cpu 12 \
    --cpu-method matrixprod \
    --timeout 65s \
    --metrics-brief \
    > background-stress.txt 2>&1 &
BACKGROUND_STRESS_PID=$!

sleep 5

openssl speed \
    -seconds 50 \
    -bytes 16384 \
    sha256 \
    2>&1 | tee foreground-openssl.txt

wait "$BACKGROUND_STRESS_PID"
wait "$FOREGROUND_PERF_PID"
wait "$FOREGROUND_TURBO_PID"

sudo perf sched timehist \
    -i foreground-load.data \
    --no-call-graph \
    -M -V \
    > foreground-load-sched.txt

grep -E 'openssl|stress-ng-cpu' \
    foreground-load-sched.txt \
    > foreground-load-workloads-sched.txt

This test exposes the clearest scheduler weakness so far. The foreground OpenSSL thread received CPU time immediately, but Linux left all 12 low-priority background workers on the P- and E-cores and placed the ordinary-priority foreground thread entirely on LP E-cores.

Foreground Workload

OpenSSL used CPU 13 for 41.848 seconds, CPU 14 for 5.050 seconds and CPU 15 for 3.103 seconds.

All eight migrations were between LP E-cores. Six occurred during the first six milliseconds, followed by a move to CPU 14 after approximately three seconds and a final move to CPU 13 after approximately eight seconds. OpenSSL then remained on CPU 13 for the rest of the test.

The 2.908 GB/s result is 24.1% below the isolated scheduler test’s 3.833 GB/s and 24.5% below the pinned P-core baseline. It is within 0.04% of the pinned LP E-core result of 2.907 GB/s.

The throughput therefore confirms the scheduler trace: OpenSSL received LP E-core performance throughout the test.

Background Workers

During the 50-second overlap, the background workers accumulated exactly 200.001 CPU-seconds on P-cores and 400.041 CPU-seconds on E-cores. They spent no measurable time on LP E-cores.

The nice value therefore did not cause any background worker to surrender a P-core to OpenSSL. The scheduler maintained four low-priority workers on the P-cores and eight on the E-cores for the entire overlap.

Background throughput fell by only 1.31% compared with the earlier 12-worker result. Rather than transferring capacity from the background workload, Linux added the foreground thread to one of the otherwise unused LP E-cores.

Frequency and Power During the Overlap

The utilisation corresponds almost exactly to 13 saturated CPUs: four P-cores, eight E-cores and one LP E-core.

Scheduler Interpretation

This is a mixed result. Scheduling latency was excellent, so the foreground process did not have to wait for CPU time. However, it received substantially less processing capacity than expected from an ordinary-priority task competing with 12 workers running with a nice value of 19.

In this test, niceness affected neither core-class placement nor the distribution of the background workers. Because an LP E-core was idle, Linux placed OpenSSL there instead of pre-empting a low-priority worker on a busy P-core. The scheduler maximised total throughput and avoided disturbing the established background workload, but it did so at the cost of approximately 24% of the foreground thread’s performance.

For this constructed desktop-style test, that is not the ideal result. Linux recognised the core-capacity hierarchy correctly when all tasks had the same priority, but it did not combine that hierarchy with process priority in the expected way. The foreground task remained responsive in latency terms, yet it never obtained the faster P-core capacity that the low-priority background workload was consuming.

Next page: Page 8 – Foreground Work with All 16 CPUs Busy

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: