MINISFORUM M2 – Does Linux Schedule Panther Lake Correctly?

Test 3 – Scaling from 1 to 16 CPU Workers

I next progressively increase the number of continuously runnable processes.

cd ~/m2-scheduler-tests

for n in 1 4 8 12 16; do
    sudo -v

    sudo perf sched record -a \
        -o "workers-$n.data" \
        -- sleep 70 \
        > "workers-$n-perf-record.txt" 2>&1 &
    workers_perf_pid=$!

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

    sleep 2

    stress-ng \
        --cpu "$n" \
        --cpu-method matrixprod \
        --timeout 60s \
        --metrics-brief \
        2>&1 | tee "workers-$n-workload.txt"

    wait "$workers_perf_pid"
    wait "$workers_turbo_pid"

    if [ "$n" != "16" ]; then
        sleep 60
    fi
done

for n in 1 4 8 12 16; do
    sudo perf sched timehist \
        -i "workers-$n.data" \
        --no-call-graph \
        -M -V \
        > "workers-$n-sched.txt"

    grep 'stress-ng-cpu' "workers-$n-sched.txt" \
        > "workers-$n-stress-ng-sched.txt"
done

Scheduler Placement

The results show that Linux follows Panther Lake’s CPU capacity hierarchy correctly. The scheduler fills the P-cores first, followed by the E-cores, and reserves the LP E-cores until all 16 CPUs are required.

The figures below represent aggregate CPU time across all workers.

For the steady-state figures, I exclude migrations during the first and final second of each workload.

The single worker initially ran on an E-core but moved to a P-core within approximately 133 milliseconds. The four-worker workload settled onto all four P-cores within approximately 160 milliseconds. Neither configuration recorded another migration during the steady portion of the test.

With eight workers, the scheduler used all four P-cores and four E-cores. With 12 workers, it used all four P-cores and all eight E-cores. LP E-core residency remained below 0.06% in both tests and consisted only of brief transitional placements.

Only the 16-worker test placed sustained work on the four LP E-cores. Its residency percentages closely match the processor’s physical distribution of four P-cores, eight E-cores and four LP E-cores.

The eight- and 12-worker tests produced more migrations after their initial placement. However, the scheduler preserved the appropriate overall division between the core classes. This represents occasional load balancing rather than continuous movement of the entire workload.

Performance, Frequency and Power

The frequency, power and temperature figures below are averages from the full-load turbostat intervals 4 to 61. The temperature column reports the highest recorded temperature during those intervals.

The average busy frequency falls as more core types become active and the processor’s shared power and thermal budgets become more important. Breaking the figures down by core class makes this clearer.

Although stress-ng reported that the scaling governor was set to powersave, this clearly did not prevent the processor from boosting. The P-cores operated at approximately 4.2 GHz during the lighter workloads.

The 16-worker run shows a distinct power-management transition. It initially averaged approximately 3,348 MHz while consuming 59.1 W. After around 37 to 38 seconds, it settled at approximately 2,916 MHz and 44.7 W.

This behaviour strongly suggests that the short-term turbo power window expired and the processor subsequently operated close to a long-term package power limit of 45 W. It is not evidence of a scheduler problem. Confirming the precise limiting mechanism would require power-limit or throttling counters that were not included in this capture.

The stress-ng bogo-operation figures are internal work units rather than an absolute measure of performance. They are nevertheless useful for comparing these otherwise identical runs. Total throughput increased from 2,445 bogo operations per second with one worker to 38,128.52 with 16 workers, representing 15.59 times the single-worker result.

Overall, the scheduler behaves very well. It selects the highest-capacity cores first, almost entirely avoids the LP E-cores until they are needed, and maintains the intended distribution between the three core classes. Even with every CPU active and the package settling to its sustained power limit, the 16-worker workload achieved close to linear scaling.

Next page: Page 6 – Real-World Multithreaded Scheduling with FFmpeg

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: