MINISFORUM M2 – Does Linux Schedule Panther Lake Correctly?

Test 2 – Bursty Single-Thread Scheduling

A permanently saturated thread isn’t representative of many desktop applications. The second test examines how the scheduler handles a thread that repeatedly alternates between working and sleeping. I’m particularly interested in which core type handles each burst, how quickly operating frequency rises, and whether the thread returns to the same CPU after waking.

Applications commonly perform a short burst of CPU activity and then wait for input, I/O or another event.

For this test, I use a single stress-ng CPU worker configured for approximately 20% load. The worker runs for 100 milliseconds and then sleeps for approximately 400 milliseconds, creating a repeatable series of CPU bursts.

To ensure that the entire workload is captured, I start perf sched and turbostat from the same shell before launching stress-ng. Both monitoring tools run for 70 seconds, while the workload starts after a two-second delay and runs for 60 seconds.

The workload itself is:

cd ~/m2-scheduler-tests
sudo -v

sudo perf sched record -a \
    -o bursty.data \
    -- sleep 70 &
BURST_PERF_PID=$!

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

sleep 2

stress-ng \
    --cpu 1 \
    --cpu-load 20 \
    --cpu-load-slice 100 \
    --timeout 60s \
    --metrics-brief \
    2>&1 | tee bursty-workload.txt

wait "$BURST_PERF_PID"
wait "$BURST_TURBO_PID"

The bursty test produced a very different scheduling pattern from the saturated OpenSSL workload.

The stress-ng-cpu worker remained exclusively on E-cores. It spent 38.18% of its execution time on CPU 7, 32.64% on CPU 8, 18.08% on CPU 9 and 11.10% on CPU 5. It never ran on a P-core or LP E-core.

The worker migrated 143 times. Twenty-five migrations occurred during its initial start-up period; the remaining 118 occurred during the steady workload. These steady migrations were separated by an average of 0.509 seconds, closely matching the 100 ms busy and approximately 400 ms sleeping cycle. Linux therefore moved the worker to another E-core on almost every wake-up.

Although individual CPU placement was not stable, core-type placement was completely consistent. Linux recognised that the intermittent 20% workload did not require P-core performance and kept it within the E-core group. Wake-up response was also quick: scheduling delay averaged only 68 microseconds and never exceeded 178 microseconds.

The worker accumulated 12.03 seconds of user and system time during the 60-second test, almost exactly matching the requested 20% load. The active E-cores averaged approximately 1,183 MHz while busy, while package power remained close to idle at 3.045 W. The E-core group averaged 97.0% C6 residency, and the unused LP E-cores averaged 99.5%.

Overall, this is a good scheduler result. Linux kept the intermittent workload on the more efficient E-cores, avoided unnecessary P-core activity and delivered consistently short scheduling delays. Although the worker moved between E-cores on most wake-ups, it remained within the appropriate core class and the migrations produced no obvious penalty in this test.

Next page: Page 5 – Scaling from 1 to 16 CPU Workers

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: