Tail Wakeup Latency on Intel Hybrid CPUs: Evaluating Linux CPU Placement and Wakeup Placement Under Mixed Load

Hybrid Intel processors expose performance (P) and efficiency (E) cores to one Linux scheduler, and interactive tasks on such machines must survive periods when batch work saturates the P-cores. Intel's Thread Director supplies core-type hints, but Linux still chooses the final CPU in the wakeup path. We measure wakeup tail latency for an eight-worker schbench probe while twelve sysbench threads occupy all P-core SMT siblings on an Intel Core i7-13650HX running Linux 7.1.8 with EEVDF. In 30 paired runs, we compare floating affinity (CPUs 0–17) with pinning to a six-E-core test pool (CPUs 12–17). The distribution body is unchanged: median wakeup latency is 43 µs floating and 44 µs pinned. The per-run maximum, which schbench reports as p99.9, diverges: median 162 µs floating versus 701 µs pinned, while the worst cases are 2836 µs and 2852 µs. Pinning moves mass into the 250–1000 µs band but does not remove multi-millisecond events: 5/30 floating and 4/30 pinned runs exceed 1 ms. A paired test does not establish a reliable ranking (Wilcoxon p = 0.17), because the distributions cross. A separate 30 s trace over 707 wakeups shows that all nine wakeups slower than 100 µs hit an occupied target CPU; four were placement races, including one pair 4 µs apart. Blanket E-core pinning trades a rare cross-domain placement for queueing delay; it is not a tail-latency fix.