MINISFORUM M2 – Does Linux Schedule Panther Lake Correctly?

Conclusions

Panther Lake is not being mistaken for a processor with 16 identical cores. Linux clearly recognises the hierarchy inside the Core Ultra 7 356H: P-cores receive the highest scheduler capacity, E-cores sit below them and LP E-cores form a distinct third tier. Under CachyOS, hybrid CPU capacity scaling is active and the scheduler uses that information effectively in most of these tests.

The pinned OpenSSL measurements establish why placement matters. An E-core delivers 80.3% of the SHA-256 performance of a P-core, while an LP E-core delivers 75.4%. Choosing the wrong core class can therefore reduce single-thread performance by around a quarter.

The uncomplicated workloads produced the strongest results. A sustained OpenSSL thread spent 99.77% of its execution time on a P-core and achieved virtually the same throughput as the pinned P-core baseline. The bursty workload stayed entirely on E-cores, where it received sufficient capacity without unnecessarily waking a P-core. Its average scheduling delay was only 68 microseconds.

The worker-scaling tests were equally convincing. Linux filled the four P-cores first, added E-cores as the worker count increased and almost entirely avoided the LP E-cores until all 16 CPUs were required. With 16 workers, CPU-time residency matched the processor’s 4:8:4 core distribution almost exactly, and throughput reached 15.59 times the single-worker result.

FFmpeg demonstrated why a migration count cannot be judged in isolation. Its large pool of short-running threads generated 460,354 migrations in 60 seconds, yet encoding remained stable at approximately 300 frames per second, scheduling delays stayed low, and frequency and power consumption remained broadly stable. The number looks alarming, but the workload showed no obvious resulting performance problem.

The priority tests revealed a more interesting limitation. With 12 low-priority background workers occupying all four P-cores and all eight E-cores, Linux placed the normal-priority OpenSSL thread entirely on an otherwise idle LP E-core. The foreground process started promptly, but its throughput was approximately 24% below the isolated P-core result. None of the low-priority workers surrendered a faster core.

When all 16 CPUs were already occupied, normal priority finally affected CPU-time allocation. OpenSSL displaced almost exactly one CPU’s worth of background work and maintained millisecond-scale scheduling delays. However, it migrated 827 times across all three core classes and received only 29.23% of its execution time on P-cores. Its effective wall-clock throughput remained approximately 25% below the isolated result.

This distinction is central to my conclusion. Linux understands Panther Lake’s performance hierarchy and uses it well when placing equal-priority workloads. What it does less successfully is combine that hierarchy with process priority. Niceness determines who receives CPU time once tasks compete on fully occupied CPUs, but it does not guarantee that the higher-priority task receives the highest-capacity core.

The full-load tests also expose the M2’s power envelope. With every CPU saturated, package power initially approached 60 W before settling at approximately 45 W, while average busy frequency fell to around 2.94 GHz. That transition is a power-management limit rather than a scheduling failure.

So, does Linux schedule Panther Lake correctly? Most of the time, yes. It recognises all three core classes, makes strong placement decisions for sustained and bursty work, scales cleanly across the processor and delivers low scheduling latency. The weakness appears when ordinary foreground work competes with low-priority CPU-intensive tasks: Linux protects total throughput and uses available cores, but it does not consistently protect foreground single-thread performance.

For the workloads tested, the results are broadly encouraging. For anyone expecting a normal-priority task to automatically displace background work from a P-core, they are less reassuring. Linux understands Panther Lake’s map; it does not always choose the route a desktop user would prefer.

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: