Masters portal

Topic selectiontopic-selection/reports/power-and-sched-ext

Report: Power Capping and sched_ext

Produced 26 August 2026 by a literature-check agent instructed toward skeptical calibration rather than encouragement, and required to verify every citation in search results rather than recall it. Reproduced verbatim; its verification caveat is at the end.

Topics checked: power-capped / energy-aware inference scheduling; learned thread placement on heterogeneous CPUs via sched_ext.

TOPIC A: Power-capped / energy-aware inference scheduling

1. CROWDEDNESS: 3 (very crowded / effectively closed.) Four-plus groups have published on exactly this knob-set in 18 months, including one preprint that matches the proposed contribution almost line-for-line.

2. STRONGEST / MOST RECENT WORKS

  • throttLL'eM: Predictive GPU Throttling for Energy Efficient LLM Inference Serving, HPCA 2025, arxiv.org/abs/2408.05235. ML predictor of KV-cache/batch drives per-iteration frequency; 43.8% energy cut under SLO.
  • DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency, HPCA 2025, Microsoft Research. Co-tunes instance count, parallelism, and GPU frequency; 53% energy saved.
  • VoltanaLLM: Energy-Efficient and SLO-Aware Disaggregated LLM Serving, ISC High Performance 2026, arxiv.org/abs/2509.04827. Establishes the U-shaped energy-frequency curve and per-iteration frequency control in SGLang.
  • PALS: Power-Aware LLM Serving for Mixture-of-Experts Models, arXiv preprint, May 2026, arxiv.org/abs/2605.21427. Treats the power cap as a first-class knob jointly with batch size and tensor parallelism; publishes exactly the HW-only/SW-only/joint Pareto comparison.
  • PowerSlider: Exploiting Phase Asymmetry for LLM Serving under Demand Response, arXiv preprint, August 2026, arxiv.org/abs/2608.21719. Takes a time-varying cap as input, which was the last unclaimed framing.

3. IS THE MVP DONE? Yes. PALS is your MVP: measured joules-per-token Pareto frontier, offline power/throughput model, online controller beating fixed configurations, on vLLM, using NVML.

4. SURVIVING GAP: Thin. The narrowest unclaimed slice: none of these tune the model variant (quantization/distilled sibling) as a third knob, and all are GPU-only — RAPL and CPU-side energy are absent. A defensible question: "under a hard cap, when does switching model variant dominate frequency and batch tuning?" This is a weak thesis, not a strong one.

5. HARDWARE BAR: Not reachable. Competitive papers use 4-8× A100 or DGX-A100 nodes with prefill/decode disaggregation across instances. Single-consumer-GPU energy work exists (RTX 4090/4060 Ti, arXiv 2608.00008, arXiv 2608.01250) but publishes as measurement studies, not systems papers.

TOPIC B: Learned thread placement on heterogeneous CPUs via sched_ext

1. CROWDEDNESS: 2 (active, room remains) — but your stated baseline is wrong. The field is thinly published academically yet densely occupied by production engineering, so beating EEVDF is no longer a contribution.

2. STRONGEST WORKS AND PRODUCTION SCHEDULERS

  • Improved load balancing with machine learning, LWN, August 2025, lwn.net/Articles/1027096 (Ching-Chun Huang, OSS-NA 2025; slides). A scx_rusty-derived scheduler trains a user-space model, ships it via a BPF map, and beats EEVDF by 10% on kernel compile with 77% fewer migrations. This is your MVP, already built.
  • sched_ext upstream patch set / OVERVIEW.md, lwn.net/Articles/972075. Meta's 16-hidden-unit neural net predicting CPU yield gave 15% nginx throughput at 87% accuracy — in-scheduling-path learning is a solved feasibility question.
  • scx_lavd (Valve/Igalia, production on Steam Deck; Meta adopting as default fleet scheduler per Phoronix/LPC 2025), docs. Already creates per-LLC, per-core-type (P/E, big/LITTLE), per-NUMA domains, with an energy model, core compaction, and autopilot power modes.
  • Evolving sched_ext: Resource Control, Topology Awareness, and Energy Efficiency, OSPM 2026, LWN report / Igalia slides. Capacity- and frequency-invariant load metrics make P-core, E-core, and LP-E-core loads directly comparable — the hard part of your problem, hand-solved.
  • scx_p2dq and scx_pandemonium, in-tree at github.com/sched-ext/scx. p2dq is explicitly the energy-aware big.LITTLE recommendation; pandemonium already classifies every task by wakeup frequency, context-switch rate, runtime, and sleep pattern and adapts online, with published EEVDF comparisons.
  • Towards Agentic OS: An LLM Agent Framework for Linux Schedulers (SchedCP), arXiv 2509.01245. Synthesizes BPF schedulers automatically; 2.11× p99 improvement on schbench.

3. IS THE MVP DONE? Partly — the weak version is done, the specific version is not. Huang did "learned predictor in a BPF scheduler beats EEVDF." Igalia/Valve and the p2dq authors did "heterogeneity-aware P/E placement," but with hand-tuned heuristics, not learning. Nobody I can verify has done learned per-task P/E-core sensitivity.

4. SURVIVING GAP: Yes. "Can a PMU-derived online predictor of a thread's core-type sensitivity — its memory-boundedness and IPC ratio between P- and E-cores — outperform scx_lavd's capacity-invariant load balancing on mixed interactive-plus-batch workloads, or do hand-tuned invariants already capture the available signal?" Own it honestly, including a negative result. Two conditions: benchmark against scx_lavd and scx_p2dq, not EEVDF, and report joules alongside latency, since these schedulers already optimize energy.

5. HARDWARE BAR: Yes, fully reachable. One hybrid box is the standard: OSPM 2026 discussion centered on a single Intel Meteor Lake machine; scx_lavd targets single-socket/single-CCX handhelds. A Meteor Lake or newer laptop, or any Arm big.LITTLE board, plus kernel 6.12+ and schbench, puts you at parity with the people doing this work. This is the decisive advantage of Topic B over Topic A.

Verification caveat: for Topic B I found no peer-reviewed conference paper (OSDI/SOSP/ATC/EuroSys/ASPLOS 2024–2026) on learned sched_ext placement. The strongest work is conference-talk, LWN, and repository engineering. I could not verify that no such paper is under submission.