COSCUP 2026Taipeisched_ext / Linux kernel

scx_lavd

Latency-criticalityAwareVirtualDeadline

A Linux CPU scheduler written in BPF that figures out which of your threads are urgent — without anyone telling it.

Speaker: Gavin Guo · Igalia scx_lavd author: Changwoo Min · Igalia, sponsored by Valve ~12,100 lines · 904 commits · since March 2024

§1OriginIgalia, 2023

It started with strace and a hunch

In 2023 SteamOS still ran CFS, and tuning the scheduler meant a handful of debugfs knobs. Igalia asked a blunter question:

Can we build a gaming-optimised scheduler on sched_ext?

~80%of syscalls were futex

Most of what strace saw was Wine synchronisation — tasks waiting on each other.

Figure: Changwoo Min, OSS NA 2024 · Igalia VaporMark

sched_ext reached mainline in 6.12, over a year later

02 / 22How it started2.3 min

Quick bit of history, because the whole design falls out of one afternoon with strace - and one picture of what a game actually looks like.

Beats

2023: SteamOS ran CFS, tuning meant a few debugfs knobs
strace on a Steam game: about 80% of syscalls were futex
That is Wine synchronisation - tasks waiting on each other
The graph: four workers wake one dxvk thread; audio threads wake each other
Communication-bound, not compute-bound. Everything follows from that
sched_ext only reached mainline in 6.12, over a year later

Detail & numbers

The 80% is not that games are cheap to compute - what they mostly do is wait. Wine maps Windows sync onto futexes.
The graph is one real trace: four Task worker threads all wake dxvk-cs, which wakes dxvk-submit; winepulse_main and winepulse_timer wake each other. Bracketed numbers are wake counts. Adapted from Changwoo Min, OSS NA 2024; tool is Igalia's VaporMark.
The number behind the design: 70-75% of scheduling in a game is initiated by a blocking syscall - epoll, pipe_read, futex_wait - and only 25-30% by preemption or the timer tick. So LAVD instruments the sleep and wake edges, not the tick.
About 300 tasks are scheduled while a game runs, ~90% never exit, and the top 30-40 account for 95% of all scheduling. wineserver runs ~260 us per schedule.
Utilisation is 65-95%, never 100%: busy but not out of capacity - so stuttering is an ordering problem, not a throughput one.
Three properties: communication-intensive, short-running (most tasks under 1 ms), semi-periodic - past behaviour predicts future.
Evidence, design, validation: the interactions proved heavily connected and statistically stable; LAVD infers latency criticality from wake-up frequency and boosts critical paths via virtual deadlines; validation was months of manual cross-checking in real games.

If asked

Why not just fix CFS? In 2023 the tuning surface was a few debugfs knobs, and a gaming-specific policy is not something upstream would want in the fair scheduler.
Is 80% futex specific to Proton? Largely yes, Wine maps Windows sync onto futexes. Native Linux games are chatty too, just less extremely so.
Which games? Igalia's VaporMark traces of SteamOS titles; the tool is open source if you want to reproduce it.

§2MotivationWhy a new scheduler

Average throughput is a lie your users can feel

A steady 144 FPS and 144 FPS with one 40 ms hitch per second have the same average — only one is playable.

The frames that ruin it were spent waiting in a run queue, not rendering.

tail latency 1% lows frame pacing wake-up latency

Same workload, two schedulers — kept anonymous as A and B. Measured and published by Changwoo Min, OSS NA 2024. B peaks higher and averages only a little lower; its worst 1% is where the stutter people complain about lives.

03 / 22The stutter problem0.8 min

Average throughput is a lie your users can feel. Two games both average 144 FPS; only one of them is playable.

Beats

Same average, one hitch per second — different experience
The bad frames are frames spent RUNNABLE, not rendering
A game is a graph of tiny chatty threads, not one hot loop
Fairness-and-throughput schedulers cannot tell them from a compile job

Detail & numbers

A steady 144 FPS and 144 FPS with one 40 ms hitch per second have identical averages. Only one of them is playable, and the average cannot tell you which.
The frames that ruin the experience are the ones where a 16 ms budget got spent waiting in a run queue instead of rendering. At 60 Hz the frame budget is 16.6 ms.
A modern game is not one hot loop - it is a graph of tiny, chatty threads: input, simulation, render submit, audio, plus shader compile and asset streaming. Most of those run for microseconds and then block.
A scheduler optimising for throughput cannot tell any of those threads apart from a compile job. From its point of view they are all just runnable work asking for a share of CPU.
The two traces are Changwoo Min's own measurements, from his OSS NA 2024 talk: same workload, two schedulers. He anonymised them as A and B on purpose - do not speculate about which is which.
His metric mapping: Avg FPS is the throughput of FPS, Low 1% FPS is 99p latency, Low 0.1% FPS is 99.9p latency. That is what makes an FPS chart a latency chart.
The punchline to say aloud: B has a higher peak and a worse experience. 34.2 average looks survivable until you see its worst 1% collapse to 4.6 FPS - which is where the stutter people complain about actually lives.

If asked

Isn't this what nice values are for? Nice controls share of CPU, not when you get it; it cannot express 'this thread is on a 16 ms critical path'.

§3Historysince March 2024

Two and a half years, one path

Each segment is coloured by the act of this talk that covers it — criticality and deadline, topology, power — so this map is also the route ahead. Today: 904 commits, 42 contributors, ~12,100 lines.

04 / 22The trail1.6 min

This is the whole project on one map. The climb is scope, not time: it starts as a single global run queue and ends topology-, power- and cache-aware.

Beats

March 2024: one global run queue, one deadline, one idea
The climb is scope — preemption, then power, then topology, then cache locality
Segment colours are the acts of this talk, so the map is also the route
Forty-two contributors: this is not one person's project any more
April 2026 is my own work; July 2026 is the newest commit in the tree

Detail & numbers

Read the shape, not the dates: one queue and a deadline in March 2024; preemption and CPU frequency scaling; core compaction in June 2024, which is where power entered the model at all; then the logical clock, power profiles and --autopilot.
September 2024 is forward propagation — a waker's urgency carried to its wakee, so a chain keeps its momentum. The backward half, boosting a low-priority waker that a critical task is waiting on, did not land until January 2026. Sixteen months apart: the design was incremental, not planned up front.
September 2025 moved the task context into the BPF arena. No user-visible feature, and the single biggest internal change in the project.
The recent end is mostly David Dai's: per-CPU DSQs for pinned tasks in November 2025, steady versus turbulent tiers in March 2026, task warmth in July 2026. April 2026, the budget-controlled fair-share load balancer, is mine — the one waypoint I can answer from the inside.
904 commits, 42 contributors, roughly 12,100 lines. The Criticality propagation slide covers the inheritance caps; here the waypoints only mark when each half arrived.

If asked

Is the core idea still the same? Yes. Everything after the first waypoint is refinement around one ordering key; nothing has replaced the virtual deadline.
What is not on the map? CPU hotplug and cross-domain stealing in December 2024, symmetric lag rewards and penalties in January 2026, --partial mode in February 2026, ops.dump_task() and SCX_ENQ_IMMED in March 2026. Waypoints are spaced by milestone, not by date.

§4Latency criticalityWho wakes whom

Waker and Wakee are the keys

Task graph · event-driven systems are graphs

Delay B and you delay everything downstream of it.

05 / 22Waker and wakee1.0 min

Everything hinges on one question: which threads are urgent? Nobody is going to annotate their threads for you, so the only evidence available is who wakes whom. Waker and wakee are the keys.

Beats

Nobody annotates their threads, so behaviour is the only evidence
Every wake-up has two ends: a waker and a wakee
wait_freq is how often B blocks on A; wake_freq is how often B unblocks C
Delay the task in the middle and you delay the whole chain

Detail & numbers

The honest way to know is to ask the developer — latency-nice, a cgroup knob, sched_setattr(). That works for exactly the software you control.
It does not work for the Windows game under Proton, the closed-source anti-cheat, or the 30-year-old daemon.
So LAVD infers it. From behaviour. At runtime. For free.
The bet is that how a task communicates tells you what it is for. A thread that wakes every 5 ms and runs for 80 µs is an audio mixer whether it says so or not.
In the figure, B's scheduling latency is multiplied by everything downstream of it — delay B and you delay C, and whatever C wakes after that.

If asked

Can't applications opt in anyway? Yes — there is a --partial mode where only opted-in tasks are scheduled by LAVD, and nice values still feed the score.

§5Latency criticalityWhat gets measured

Three signals

wait_freq

How often the task sleeps waiting on something external — I/O, a timer, a packet, a mutex.

wake_freq

How often the task wakes somebody else.

runtime

Average invariant runtime per schedule. Shorter is more critical

High wait and high wake means the task sits in the middle of a chain — the most expensive place to introduce delay.

06 / 22Three behavioural signals1.3 min

Three signals, no annotations. Two frequencies and one duration, and that's the whole sensor set.

Beats

wait_freq — how often it sleeps waiting on something: consumer signal
wake_freq — how often it unblocks somebody else: producer signal
runtime — shorter is more critical: inverse signal
High wait AND high wake means middle of a chain

Detail & numbers

wait_freq is measured in ops.quiescent() as an EWMA of 1 s divided by the interval between sleeps — I/O completion, a timer, a packet, a mutex.
wake_freq is charged to the waker, not the wakee, at ops.runnable() time. A thread that unblocks others is on somebody's critical path.
runtime is average invariant runtime per schedule: a 60 µs task cannot absorb a 3 ms delay, a 40 ms batch job barely notices.
Read as a set: wait_freq is the consumer signal, wake_freq the producer signal, and runtime an inverse one — the longer a task runs, the less critical it is.
Both frequencies are clamped at LAVD_LC_FREQ_MAX = 100,000/s — a 10 µs interval — because past that you are measuring noise, not urgency.
The formula multiplies wait by wake specifically to reward sitting in the middle of a chain, the most expensive place to introduce delay.

If asked

Can a task game these signals? In principle yes, by faking chatty wake-ups; in practice the frequency clamp and the greedy penalty on over-served tasks limit how much it buys you.
What about a thread that is both urgent and long-running? It scores mid-range: the frequency terms lift it, the runtime term pulls it down.

§6Latency criticalitylat_cri.bpf.c

Turning behaviour into a number

lat_cri ∝ wait_freq × wake_freqruntime

In the code it is log-compressed, then squared: lat_cri = ( log₂(wait_ft·wake_ft) + log₂(rt_ft·w_ft) )²

A task that waits often, that wakes others often, and that runs only briefly sits in the middle of a chain — so it scores highest, and the scheduler runs it first.

07 / 22calc_lat_cri()1.1 min

One line to remember: waits often, wakes others often, finishes quickly. Say the proportional sign out loud — the code log-compresses and squares, and every piece of it is defensible.

Beats

lat_cri ∝ wait_freq × wake_freq ÷ runtime — that is the whole intuition
Proportional, not equal: read the small line, it is log-compressed then squared
wait × wake, not wait + wake — the middle of a chain wins
Then normalised to [0, 1024] — the number the rest of the talk uses

Detail & numbers

The exact function: lat_cri = ( log2(wait_ft·wake_ft) + log2(rt_ft·w_ft) )², where wait_ft is min(wait_freq, 100k) + 1, wake_ft is min(wake_freq, 100k) + 1, rt_ft is (1 s minus avg_runtime_invr) divided by 500 µs, plus one, and w_ft is weight times boost, plus one. Runtime enters through rt_ft, inversely — which is what the division on the big line expresses.
Why multiply wait by wake instead of adding them: the product is only large when both are large, so it rewards sitting in the middle of a chain rather than at either end.
Why log2: a spinning thread wakes 100,000 times a second, a cron job wakes twice an hour. Raw values would let one pathological thread dominate every comparison.
Why square: logs compress too well, so squaring re-expands the top of the range and genuinely urgent tasks separate from merely busy ones.
The weight boost ladder is powers of two from 128: 128 for a regular lock holder needing a boost, 256 and 512 for medium and high, 1024 for kernel tasks and sync wake-ups. That is the w_ft term, and it is what keeps nice values meaningful.
lat_cri is finally normalised to [0, 1024] for CPU-selection and DSQ-routing decisions.

If asked

Where did the constants come from? Empirically, from gaming and desktop workloads; they are not derived from a model, and most are exposed as command-line knobs.
Is log2 not expensive in BPF? It's an integer log2x() helper, and it is deliberately marked noinline to keep the caller's verifier complexity down.

§7Latency criticalityContext awareness

Urgency is contagious — Latency Inheritance.

key press propagation chain

LAVD reads tasks as a connected graph, not in isolation: urgency flows forward to whoever you wake, and backward to whoever is blocking you.

Bounded inheritance

08 / 22Criticality propagation1.3 min

One job, not seven tasks. Urgency is inherited along the chain in both directions — and only a bounded fraction of it ever travels.

Beats

One job, not seven strangers: key press, input interrupt, input thread, game, render submit, display refresh, frame
Forward propagation: the wakee inherits some of the waker's urgency, so the chain keeps moving
Backward propagation: a task blocking a critical one gets boosted — priority inversion by measurement, not by protocol
Capped and decaying: say this aloud, because nothing on the slide implies a limit any more

Detail & numbers

Say the bound aloud; nothing on the slide implies one any more. Inheritance applies only when the giver, lat_cri_waker + lat_cri_wakee, exceeds 2 × lat_cri. The giver contributes at most 12.5% of the surplus (>> 3), the receiver gains at most 25% of its own score (>> 2), and both accumulators reset on every lat_cri recompute — without the caps, an A wakes B wakes A cycle inflates both without bound.
Forward and backward in full: forward, a waker lends urgency to its wakee, so the whole chain keeps moving; backward, a critical task waiting on a low-priority one lifts it — priority inversion solved by measurement, not by protocol.
Older schedulers judged every task in isolation; LAVD reads them as a connected graph carrying one job, key press to frame, where nothing on the path waits its turn. Inheritance is capped and decays: woken once is not urgent for ever, because baseline scores pull it back.
Changwoo Min's framing, worth attributing: tasks form a connected, cyclic graph, not isolated entities. Chains start at an input interrupt and end at the display refresh interrupt, so interrupt-woken tasks are their natural heads. Boosting foreground UI tasks explicitly, the iOS approach, would not transfer to servers, so LAVD infers the chain instead.
Changwoo's stress test, if asked: a WebGL aquarium with 30,000 fishes, YouTube streaming, make -j128 on the kernel and a strategy game at once — he reported it stayed smooth.

If asked

Isn't this just priority inheritance? Same goal, different mechanism: no protocol, no ownership tracking, just a bounded score nudge that decays.

§8Deadlinecalc_when_to_run()

How do we deduce a task's deadline?

deadline_delta = adjusted_runtime × greedy_penaltylat_cri vdeadline = logical_clk − compete_window + delta

Everything the scheduler knows collapses into one number — and lat_cri divides, so ten times more critical means a tenth of the distance to wait. The clock keeps advancing, so even the least critical task eventually wins: priority that decays into fairness.

09 / 22The virtual deadline1.6 min

Everything the scheduler has learned collapses into one division. This is the ordering key, and there's nothing else in the queue.

Beats

deadline_delta = adjusted_runtime × greedy_penalty ÷ lat_cri
vdeadline = logical_clk − compete_window + delta
Tasks sit in a vtime-ordered DSQ; dispatch pops the smallest
No real time appears anywhere in the ordering

Detail & numbers

The DSQ is sorted by the deadline; dispatch pops the smallest.
adjusted_runtime is 5 ms plus the invariant time burned since the last sleep, capped at 5 ms — a task that just woke beats one that has been grinding.
greedy_penalty runs 1.0× to 2.0×, derived from the fairness lag — the gap between the CPU time a task should have got and what it did. Over-served tasks get pushed back.
lat_cri divides: ten times more critical means a tenth of the deadline distance.
The animation places five tasks at clk − window + delta and pops the leftmost. Watch batch, the least critical: it loses every round until the clock drifts past it, then wins anyway.
No real time appears in the ordering. cur_logical_clk is a global cursor advanced by compare-and-swap in ops.running(), stepping toward the deadline of whichever task actually ran.
New arrivals start one full COMPETE_WINDOW behind the cursor, so a fresh wake-up genuinely competes. The window is not a constant: calc_compete_window() shrinks it by nr_active/nr_queued once the backlog outgrows the active CPUs.
Why it must shrink: a task whose delta is smaller than the window lands behind cur_logical_clk and cannot advance it, so a large window leaves nothing ageing the clock and dl_delta the only fairness mechanism. David Vernet, July 2026, off a hackbench regression.

If asked

Doesn't the least critical task starve? No — it loses every round until the logical clock drifts past it, then it wins anyway. Priority that decays into fairness.
Isn't a global CAS-updated clock a scalability problem? It is a single cacheline updated in ops.running(), and it is one of the reasons per-domain DSQs exist.

§9DeadlineHow long, not just when

How long should a task run?

slice = targeted latency 10 ms × active CPUsqueued tasksclamped to [500 µs, 5 ms]

Every queued task should get a turn within 10 ms, across all the active CPUs — so the slice is that budget divided by how many are waiting. The clamps stop it becoming either a context-switch storm or a monopoly.

10 / 22Time slice1.3 min

The slide before answered when a task runs. This one, how long — a 10 ms budget across the active CPUs.

Beats

slice = (10 ms targeted latency × active CPUs) ÷ queued tasks, clamped to [500 µs, 5 ms]
The 10 ms window is served across the active CPUs, not one
Read the chart: the base curve is flat at both clamps, the dashed line is the boost
Boost the task that keeps getting cut off, halve the freshly forked; pinned tasks override both

Detail & numbers

Base: 10 ms targeted latency × active CPUs ÷ queued tasks, clamped to [500 µs, 5 ms]. More queued tasks, shorter slices. Say it aloud: nr_active is the core-compaction active set, which links this slide to the power section.
Empty queue short-circuits to slice_max_ns, 5 ms; the result is smoothed by calc_avg(), so the slice drifts rather than jumping each tick. Both clamps matter: no 5 ms ceiling and a lone task owns the window; no 500 µs floor and a loaded machine switches more than it runs.
Boost predicate: avg_runtime_wall >= sys_stat.slice_wall — average runtime already exceeds the slice, so the task keeps getting cut off. Not “used its whole slice”. Two paths: can_boost_slice(), not heavily loaded → avg_runtime_wall + 500 µs bonus, capped at LAVD_SLICE_BOOST_MAX, 500 ms; else under load, only lat_cri above the system average, scaled by criticality, capped at 2× the slice.
Why boost: cascading delay — a long task mid-chain, cut off at slice exhaustion, delays everything downstream, and that is where tail latency comes from. Not a reward for compute-bound work. A fresh fork gets half a slice: nothing is known about it yet, so information is cheap — and it brakes fork bombs.
Pinned: --pinned-slice-us, 5 ms default. With one waiting, every task on that CPU drops to min(pinned_slice_ns, sys_stat.slice_wall) and routing moves to per-CPU DSQs.

If asked

500 ms is a huge slice — doesn't that hurt latency? It only applies below 95% utilisation with nothing pinned waiting, and a more-critical wake-up can still cut its slice short so it yields at the next scheduling point.

§10Deadlinepreempt.bpf.c

Preemption mechanism

Two random probes, never a full scan — a random start in a random direction stops every CPU converging on the same victim: the thundering herd.
Only inside the task's own compute domain — the CPUs of p's domain that p may run on.
A candidate must be losing on both counts — lower lat_cri and a later predicted finish, or you evict a task that was about to release the CPU anyway.
No IPI. The victim is not interrupted — its time slice is shortened so it yields at its next scheduling point.
Never a lock holder, and only the top 1.56% of tasks may preempt at all.

11 / 22Preemption1.2 min

Picking a victim is a load-balancing problem — and, in the current code, nothing here sends an IPI.

Beats

Preemption is load balancing: find the CPU running the least critical task
Two random probes, random start and direction — or every CPU picks the same victim
Candidates come only from the task's own compute domain
No IPI: the victim's slice is shortened, so it yields at its next scheduling point

Detail & numbers

Preemption is load balancing: ideally the N most latency-critical tasks hold the N CPUs, so finding the CPU running the least critical task is the least-loaded-server problem — hence power of two random choices.
Search mask: p's compute domain ∩ p->cpus_ptr (preempt.bpf.c:423); a preferred CPU, if any, is checked before the two random probes. can_x_kick_y() requires both lat_cri(x) > lat_cri(y) and est_stopping(x) < est_stopping(y).
No IPI: scx_bpf_kick_cpu() is avoided on purpose — an IPI is expensive and its cost varies with processor architecture and generation. The victim's slice is shortened instead, so it yields at the next scheduling point. Set to 1, not 0: the core replaces a zero slice with SCX_SLICE_DFL, 20 ms.
Two CPUs can pick the same victim. Uncoordinated on purpose: the race is rare and synchronising it would cost more. Instead est_stopping_clk is compare-and-swapped to zero, so a victim is not chosen twice, and whoever wins that swap preempts.
Not attempted at all for greedy tasks (LAVD_FLAG_IS_GREEDY) or when is_worth_kick_other_task() says no. Never a lock holder: evicting a task inside a critical section turns one stall into many.
Rate limit: --preempt-shift=6 restricts preemption to roughly the top 1.56% (0.5 to the sixth) most latency-critical tasks. Known cost: worst case the traversal visits every CPU in the domain, which the source flags to revisit.

If asked

Why two random probes rather than the worst CPU? Because the full scan is O(nr_cpus) on a wake-up path and every CPU would be reading the same lines; two probes get most of the quality for a constant cost.

§11Deadlinelock.bpf.c

Who holds the lock?

priority inversion, and the fix

A latency-critical task is only as fast as whoever holds the lock it wants — so LAVD traces futex operations to find the holder, then protects and boosts it.

12 / 22Lock & futex boosting1.7 min

Priority inversion is a scheduling problem that looks like a locking problem — so the scheduler has to know who holds the lock, and knowing cheaply is the hard part.

Beats

Priority inversion: the critical task is only as fast as whoever holds the lock
A lock holder is never preempted, and gets +128 on its next deadline
The hard part: an uncontended userspace lock never enters the kernel
fentry 48 ns, fexit 76 ns, tracepoint 130 ns — attach point chosen by cost
Those three numbers are notes-only now: quote them, do not point at them

Detail & numbers

A lock holder is never preempted — evicting a task inside a critical section turns one stall into many — is kept running through ops.dispatch(), and gets a +128 weight boost on its next deadline, paid forward once, after it releases.
Attach-point costs, measured per futex operation on an AMD Ryzen 9 PRO 6950H: fentry 48 ns, fexit 76 ns, tracepoint 130 ns. BPF offers both mechanisms and userspace picks based on what the running kernel exposes: fentry is fastest but breaks if the function is inlined; a tracepoint is a stable ABI; fexit is needed where the return value matters.
Why not uprobes on pthread_mutex_lock: they would be exact, but they trap into the kernel on every acquisition and would destroy the optimisation being measured.
Why the approximation holds: a well-optimised userspace lock never enters the kernel when uncontended — NPTL skips futex_wait() if nobody is waiting — so the kernel-side view is incomplete by design. Four rules follow. No futex_wait() means nobody is waiting, so there is nothing worth boosting: the missing information is exactly the information you do not need. A repeated futex_wait() before a wake is a spurious wake-up retry, so all but the first are ignored. No futex_wake() within one time slice means assume the lock was released, since a critical section longer than a slice is not one you want to boost. And futex addresses are deliberately not distinguished, to keep tracing cheap.

If asked

Why not use PI futexes? They require the application to opt in and only cover a subset; this works on binaries you cannot change.
Could you not just trace pthread_mutex_lock in userspace? That is the uprobe, and it traps into the kernel on every acquisition — you would be adding a syscall-shaped cost to the fast path whose absence you are trying to detect.

§12Topologyops.enqueue() → ops.dispatch()

Dispatch Queue Layout

Each compute domain is one L3 cache, so a domain's queue holds tasks that already share a cache. But no CPU should sit idle while another domain has work waiting — so a CPU that runs dry may pull from beyond its own domain.

13 / 22Dispatch queue layout1.6 min

Two things at once here. What the queues actually are — and the fact that putting a task in one does not run it.

Beats

Four queues: three the BPF scheduler creates, one the kernel owns
A compute domain is one L3 cache, so its queue is a cache-local queue
ops.enqueue() only places the task; nothing runs it yet
The kernel calls ops.dispatch() only when a CPU's local DSQ has run empty
Below 10% utilisation, or onto an idle CPU, the domain queue is skipped entirely

Detail & numbers

A compute domain is one unique combination of LLC x core type x NUMA node; up to 128 of them. Aligning the queue to the LLC is the point: tasks queued together are tasks that already share a cache.
The domain DSQ is deadline-ordered, on virtual time. Domains know their neighbours at up to 3 distances, stored in circular order, so when work does have to move it moves the shortest distance first.
Three user DSQ types: CPDOM is the domain's main queue, CPDOM_TURB is the overflow tier for latency-tolerant work routed away from contended CPUs, and CPU is per-CPU for pinned tasks that cannot migrate.
The asynchrony in words: ops.enqueue() only places a task in a DSQ. The kernel calls ops.dispatch() only when a CPU's local DSQ has run empty, and LAVD then moves one task across with scx_bpf_dsq_move_to_local(). Producer and consumer are decoupled; neither blocks waiting for the other.
The bypass is can_direct_dispatch(): the target CPU is idle with nothing already queued on it, or that CPU's utilisation is below --lb-local-dsq-util-pct, default 10%. Note it is a per-CPU test, not a system-wide one. At that load there is nothing to arbitrate, so paying for deadline ordering would be waste.

If asked

How does this compare to scx_layered or scx_rusty? Same topology instincts, different policy: those partition by task class or by domain load; LAVD partitions for cache locality and orders by inferred urgency.

§13Topologystealer · stealee

Load balancer — stealer vs. stealee

LAVD is a domain-DSQ scheduler: every domain has one dispatch queue, shared by the CPUs inside it.

Stealer

An underloaded domain. It periodically pulls tasks from stealees to keep its own CPUs busy.

Stealee

An overloaded domain, carrying more queued load than its fair share. Stealers may pull from it.

Figure adapted from “Evolving sched_ext: Resource Control, Topology Awareness, and Energy Efficiency for Modern Systems” — Changwoo Min and Gavin Guo, April 2026.

14 / 22Domain DSQs and stealing1.3 min

Two words are going to keep coming back, so let me define them once: stealer and stealee. And neither is a property of a domain — both are recomputed every profiling interval.

Beats

Domain-DSQ scheduler: one dispatch queue per domain, shared by its CPUs
Stealer: underloaded, pulls from stealees to keep its CPUs busy
Stealee: overloaded, carrying more queued load than its fair share
Neither role is fixed — every domain is reclassified from scratch every 10 ms

Detail & numbers

LAVD is a domain-DSQ scheduler, not a per-CPU-runqueue one. Each domain owns one dispatch queue that every CPU in it feeds from, which is what makes the domain, not the CPU, the unit of load balancing.
The classification is recomputed every 10 ms, off the sys_stat timer, from each domain's queued load against the mean. Below the band it is a stealer, above the band a stealee, inside the band neither.
The band is not fixed either. Delta narrows as the system loads up: plus or minus 25% when idle, 12.5% at mild load, 6.25% when busy — so a busy system reacts to smaller imbalances. The figure is drawn at the 12.5% case.
The ordered fallback in ops.dispatch() when a CPU's local runqueue drains. One: if this domain is a stealer, steal from a remote stealee — that is where load balancing actually happens. Two: try the local domain's DSQ, the cache-warm common case. Three: force-steal from any nearby DSQ rather than let the CPU go idle.
Worth saying why balancing goes first. If the local queue is consulted first, a stealer never gets round to stealing while it still has anything of its own to run, so a measured imbalance persists for as long as there is local work.
Figure adapted from Evolving sched_ext — Changwoo Min and Gavin Guo, April 2026; the full title is credited on the slide.

If asked

Why not simply steal once the local queue is empty? That is the third step, and by then the CPU has already run out of work. The first step exists to close a measured imbalance before it turns into idle time somewhere else.

§14Topologyload_invr

How to calculate the queue load?

Task count says nothing about work. A domain with two heavy tasks is correctly recognised as busier than one with ten small ones.
invr is invariant runtime — scaled by CPU capacity and frequency, so loads are comparable across heterogeneous cores.

load = queued_load_invr + util_invr queued_load_invr = Σ size_of(task), over everything queued in the domain util_invr = how busy the domain's CPUs are right now

One domain's load, bottom to top

15 / 22What load actually means0.9 min

The next slide talks about load, and I have not told you what load means yet. It is not the number of runnable tasks.

Beats

Task count says nothing about how much work is queued
Two heavy tasks are busier than ten small ones
load = queued_load_invr + util_invr
invr is invariant runtime, so loads compare across core types

Detail & numbers

Per-domain load is queued_load_invr plus util_invr. queued_load_invr is the sum of size_of(task) over everything queued in the domain; util_invr is how busy the domain's CPUs are right now. So the measure covers both work waiting and work in progress.
Unlike task count, this captures actual workload: a domain with two heavy tasks is correctly recognised as busier than one with ten small tasks. Counting runnable tasks gets that exactly backwards.
invr means invariant runtime — runtime scaled by CPU capacity and frequency. That is what makes a number from a little core comparable with a number from a big core, and it is why the same arithmetic works on a hybrid laptop and on a homogeneous server.
The stacked bar is the whole slide: util_invr at the bottom, then one segment per queued task. Point at it and say that the balancer is comparing these totals, not the segment counts.
This is the term the load balancer uses on the next slide, which is why it comes first. Source: Changwoo Min and Gavin Guo, April 2026.

§15Topologybalance.bpf.c

How much load should a domain carry?

fair_share = total_queued_load_invr × domain_capacitytotal_capacity

The target is not an average. A domain with 40% of the machine's capacity should carry 40% of the queued load — so a domain holding more load than its neighbour can still be underloaded, and steal from it.

16 / 22Load balancing1.4 min

Every 10 ms each domain is measured against its capacity-proportional fair share — not an equal split, because a domain of little cores shouldn't carry a big core's worth of work.

Beats

fair_share = total queued load × this domain's capacity ÷ total capacity
Not an average: 40% of the capacity means 40% of the load
More load than a neighbour and still a stealer — capacity sets the target
Half the excess out, half the deficit in: steps, not jumps

Detail & numbers

fair_share = total queued load × this domain's capacity ÷ total capacity. A domain with 40% of the capacity should carry 40% of the queued load; big-core domains have more capacity, so a larger share. Recomputed every 10 ms on the sys_stat timer.
The target is per domain, not one average: a domain holding more load than its neighbour can still be underloaded and steal — cpdom1 at 302 against cpdom2 at 248, on 4× the capacity.
Say aloud: the flat average on the stealer-versus-stealee slide is the --no-fast-lb path; the default is this capacity-proportional fair share. On homogeneous hardware the two coincide, so the average introduces it fairly.
A stealee exports at most half its excess per round, a stealer imports at most half its deficit. That kills ping-pong (moving the whole excess overshoots, so the imbalance flips next round) and the thundering herd (uncapped, every stealer drains one domain in a round).
The deadband comes off each domain's own fair share and narrows as load rises: ±25% idle, ±12.5% mild, ±6.25% busy — a quiet machine makes imbalance cheap and migration expensive. Below 25% utilisation balancing is skipped entirely (--lb-low-util-pct).
The round ends whether or not balance was reached: steps, not jumps. Neighbours are walked in circular distance order, and empty-queue domains are skipped.

If asked

Has aggressive stealing ever backfired? Yes. Forcing steals under per-CCX pinning has been measured burning a large share of cycles in DSQ spinlock contention; the halving budgets and the empty-queue skip exist because of exactly that class of problem.

§16Topologyturbulent DSQ

Which queue does a task belong in?

Some CPUs are interrupted by things the scheduler does not control — IRQ, RT, deadline, steal. Vulnerable tasks are queued away from them; steady CPUs may still drain the turbulent queue, so the boundary stays soft.

Turbulent DSQs: David Dai, March 2026.

17 / 22Turbulent DSQs1.4 min

Some CPUs are interrupted by things this scheduler does not control — IRQ, RT, deadline and steal time. LAVD gives every compute domain a second queue for the tasks that can absorb that.

Beats

Turbulent CPUs are the ones exposed to IRQ, RT, DL and steal time
Two DSQs per domain: the regular cpdom DSQ and a turbulent one
Enqueue scores the task's preemption vulnerability against vuln_thresh
Turbulent CPUs pull from the turbulent DSQ; steady CPUs pull from both
So the partition is soft, not a wall

Detail & numbers

A CPU is steady when its latency headroom is in the top 12.5% (LAVD_LC_LATENCY_SENSITIVE_THRESH), turbulent otherwise, recomputed each tick. Each domain gets two queues: LAVD_DSQ_TYPE_CPDOM and LAVD_DSQ_TYPE_CPDOM_TURB.
Enqueue scores preemption vulnerability = (normalized_lat_cri / 64) × 16 + (util_est / 64): a 16×16 grid giving 0 to 255, latency criticality the major axis, utilisation the minor. At or above the domain's vuln_thresh the task is vulnerable and goes to the steady DSQ; below it, to the turbulent DSQ.
vuln_thresh is not fixed either: it moves every tick to hold the two tiers' load balance at --lat-load-target-pct, default 100, meaning equal per-capacity load.
Dispatch is asymmetric, and that is the design. A turbulent CPU pulls from the turbulent DSQ; a steady CPU pulls from both — the steady DSQ first, but it may also consume from the turbulent one.
The author's reason: the less turbulent CPUs can still consume from the turbulent DSQ since they are generally more responsive and have higher compute capacity. This softens the boundary between critical and non-critical tasks to help consistently make system-wide forward progress.
Source: the turbulent-DSQ series by David Dai, March 2026 — 8e4994c7626f, 8708552c4beb, e221660a606f.

If asked

Does CPU placement bias the same way? Yes. For a vulnerable task the steady set becomes the active mask and the turbulent set the overflow, so it prefers a steady CPU and falls back rather than being denied one.
How does a task get placed at all? Sync wake-up on the waker's CPU, then the sticky previous CPU, then an idle SMT-free core in the domain, then any idle CPU, then neighbouring domains up to 3 hops, then queue and consider preempting.
What is --warm-cpu-us? New in July 2026, default 0, so off. With it set, a task below the criticality threshold may wait for its previous CPU rather than migrate; over-migration thrashes the TLB and cost about 3% of IPC against EEVDF on a caching workload.

§17PowerCPU stickiness

Should a task wait for its old CPU?

Always taking the idle core maximises work conservation — and on a memory-bound service it thrashes the TLB. Migrating away from hot per-thread caches cost about 3% of IPC. So sometimes it is cheaper to wait.

Task warmth: David Dai, July 2026.

18 / 22Task warmth1.3 min

Every sched_ext scheduler here, LAVD included, migrates tasks aggressively towards a completely idle core. That is right for latency-sensitive compute work, and it is wrong for a service that is bound on memory throughput as well as compute.

Beats

LAVD always favours a completely idle core — on symmetric SMT, one whose sibling is idle
That maximises work conservation, and on memory-bound work it thrashes the TLB
Warmth is a proxy for the cache and TLB state a task built on the CPU it last ran on
Full heat after 500 µs of residence; linear decay to zero over 5 ms of away-time
Heat stretches the wait budget up to 2×, so a still-warm CPU is worth waiting for
Waiting means queueing on that CPU's own per-CPU DSQ — the queue from the layout slide

Detail & numbers

The problem, from the commit message: LAVD, like other sched_ext schedulers, aggressively migrates tasks, always favouring a completely idle core. On symmetric SMT that means picking the CPU with the most available compute — one whose sibling is idle. That maximises work conservation and suits latency-sensitive, compute-intensive work.
But for workloads that are both compute- and memory-throughput-bound, such as caching services, over-migration causes TLB thrashing and reduced IPC. Most of the extra TLB misses come from application heap accesses, and with userspace-managed allocators like jemalloc, whose per-thread caches are typically hot, this cost about 3% IPC at nominal loads versus EEVDF.
Warmth accrues in task_update_cpu_warmth(): the slice a task just ran adds to its heat, saturating at full heat after LAVD_CPU_WARM_SAT_NS = 500 µs of residence. Heat is on a 0–1024 scale and follows the CPU the task last ran on; if the task migrated, the clock restarts from that slice.
Warmth decays in task_cpu_warmth(): heat is zero for any CPU other than the one the task last ran on, and otherwise falls as heat − (heat × away_ns) / LAVD_CPU_WARM_LIFETIME_NS — a linear decay to zero over 5 ms of away-time.
The decision, warm_cpu_wait_ok(): budget = warm_cpu_ns × (1024 + heat) / 1024, so no heat gives one times the base budget and full heat gives two — a still-warm CPU earns a longer wait. wait is the time until that CPU's current task stops (est_stopping_clk − now) plus the tasks already queued ahead on its DSQ times the system-average slice. If wait ≤ budget the task waits for its old CPU, enqueued on that CPU's per-CPU DSQ by the LAVD_FLAG_WARM_CPU path; otherwise it migrates. The base budget is --warm-cpu-us, default 0, so the whole feature is off unless enabled.
The wait estimate is rough, and the source says so: it assumes the task is served last and that every queued task runs the system-average slice. A per-core queued-load figure would sharpen it, and the comment says to revisit once per-core queued load is tracked. Source: 5699c7f08582, David Dai, 21 July 2026 — util.bpf.c and lavd.bpf.h.

§18PowerThe counter-intuitive one

Spreading work across all cores can be the worst thing to do

At 20% system load, the obvious placement is 20% on each of 16 CPUs. What actually happens:

Every core sits low, so the governor holds every core at a low frequency.
Every core keeps entering and leaving C-states, paying transition energy and exit latency constantly.

Low performance and high power. The worst of both.

Compaction inverts it: fewer CPUs, driven properly, and let the rest sleep deeply.

higher clocks on active cores deeper C-states elsewhere fewer P/C transitions

Identical total work, 8 CPUs, ~25% load. Every flicker on the top half is a C-state entry and exit. The bottom half pays it a handful of times instead of continuously.

19 / 22Core compaction — the idea1.3 min

This is the counter-intuitive one. Spreading work evenly across all your cores can be the worst thing you can do.

Beats

Frame it: 20% load on 16 CPUs is 20% on each, and that is the trap
Low utilisation everywhere means low frequency everywhere
Constant C-state entry and exit costs energy and latency
Low performance AND high power — use fewer cores, drive them properly

Detail & numbers

The two failure modes are separate: the governor holds every core at a low frequency because no core looks busy, and every core keeps paying C-state transition energy and exit latency.
Compaction inverts it: use fewer CPUs, drive them properly, and let the rest sleep deeply and stay asleep. Higher clocks on the active cores, deeper C-states elsewhere, fewer P-state and C-state transitions.
In the animation both halves do identical total work on 8 CPUs at about 25% load. Every flicker on the top half is a C-state entry and exit — energy spent and latency paid to go to sleep for a few microseconds. The bottom half pays it a handful of times instead of continuously.
The one-line framing if it does not land: idle is not free, and half-idle is the most expensive state a core can be in.

If asked

Doesn't concentrating load hurt thermals? On some parts yes, which is why the preference order comes from the energy model when one exists and why the per-CPU target is only 50%.
Is this the same as the kernel's EAS? Same family of reasoning; EAS places tasks by energy model, LAVD additionally decides how many cores are allowed to be awake at all.

§19Powercalc_nr_active_cpus()

Core Compaction: How many cores are enough?

Fewer cores, driven properly, beat every core running half-idle. The only question left is how few will carry the load.

req_cap = nr_cpus_online × avg_util_invr req_cap += 25% ← spike headroom for cpu in preference_order: sum += effective_capacity(cpu) × 50% if sum ≥ req_cap: break the CPUs walked become the ACTIVE set; the rest go to OVERFLOW

20 / 22Core compaction — mechanics1.8 min

So: how many cores are enough? Four lines of arithmetic, and two constants carry all the safety.

Beats

req_cap = online CPUs × average invariant utilisation, then plus 25%
Walk the CPUs in preference order, adding 50% of each one's effective capacity
Stop the moment the running total reaches req_cap
Those CPUs are the ACTIVE set; the rest go to OVERFLOW and stay in deep idle
Preference order is not CPU number — it comes from the energy model

Detail & numbers

The 25% headroom sizes the active set for more load than currently exists, so a spike does not immediately force a re-plan. The 50% per-CPU cap targets an active CPU at half utilisation, leaving real slack for latency-critical wake-ups.
Utilisation is capacity- and frequency-invariant, so '50%' means the same thing on a little core at 1.2 GHz and a big core at 5 GHz.
Where compaction is not allowed to win: kernel and pinned tasks are exempt, already hand-placed by someone who knew more; and the overflow set is elastic — a non-active CPU that finds a pinned task or queued work adds itself and runs it.
Spike detection: utilisation near 90% expands the active set immediately. The re-plan interval is 250 ms — stable enough to be steady, short enough to track a workload change.
Preference order is not CPU number. It comes from the kernel's energy model, which the Energy Model Optimizer solves once at load time: which CPUs to wake for a given demand, at least energy. Without an energy model it falls back to a topology-derived order — turbo-capable cores first, then big, then SMT siblings last.
The figure's arithmetic is the real one. Effective capacities 1024, 1024, 768, 768, 768, 512, 512, 512 halve to 512, 512, 384, 384, 384, 256, 256, 256, so the running total steps 512, 1024, 1408, 1792, 2176. At avg_util_invr 128 the requirement is 8 × 128 = 1024, plus 25% is 1280, and three CPUs cover it; at 205 it is 1640, plus 25% is 2050, and five do.

If asked

What if the energy model is wrong or missing? The topology fallback is used, and --cpu-pref-order lets you override the order by hand.
What does this do to a benchmark that wants all cores? Nothing: at high load the arithmetic already demands every CPU, and --performance disables compaction outright.

§20Beyond gamingDirection

From games, to fleets, to GPUs

The signal LAVD measures — who is on the critical path — was never gaming-specific. Anything where tasks wait on each other has the same shape.

where it started

Gaming

SteamOS and handhelds: latency-critical, communication-heavy, and running on a battery.

where it went

Server fleets

Meta have explored scx_lavd as a default fleet scheduler — for the range of hardware and use cases where they do not need a specialised one.

reported via Phoronix

the next question

AI serving

Inference servers like vLLM and SGLang live or die on keeping the GPU busy. We are looking at whether the target should be GPU idle time, not CPU latency alone.

Two ways in, and both continue what you have already seen: categorise the workload, because the problem definition follows from what it is — then migrate selectively, per workload. Warmth already decides whether to migrate and turbulent DSQs decide where; next is deciding for whom.

21 / 22Where this goes next1.8 min

One last thing, and it is the direction rather than the destination. A scheduler written for handheld games is being looked at for server fleets — and the reason it transferred is the reason it may transfer again.

Beats

It started on SteamOS and handhelds: latency-critical, chatty, on a battery
Meta have explored scx_lavd as a default fleet scheduler
It transferred because 'who is on the critical path' is not gaming-specific
The next question is AI serving — keeping the GPU busy, not the CPU quick
Two ways in: categorise the workload, then migrate selectively
Stage three is a question we are asking, not a result we have

Detail & numbers

The Meta line is a quotation, so quote it: they explored scx_lavd as a default fleet scheduler for the range of hardware and use cases where they do not need a specialised one. Reported via Phoronix. It is an evaluation, not a declared default, and it is the deck's only third-party corroboration — do not overstate it.
Server shape if asked: one or two sockets, 12 LLC domains per socket on the AMD parts, 8 cores per domain. Not every task is short-running, L3 locality dominates, and tail latency is still the metric that matters.
Why it transferred: the same wake-up-frequency signal that found a game's critical path found a caching service's. The slice boost, the per-domain queues with a budgeted balancer, and the steady-versus-turbulent split all answer 'tasks wait on each other'.
Stage three is exploratory, and must be said as a question. Inference serving such as vLLM and SGLang is bottlenecked on keeping the GPU fed, so the objective becomes GPU utilisation — avoiding GPU idle time — rather than CPU latency alone. Nothing is implemented, and LAVD does not schedule GPUs.
Two ways in, both continuations of this talk: workload categorisation first, because the problem definition follows from the workload type; then selective migration, different tasks migrated differently per workload. Warmth already decides whether to migrate and turbulent DSQs decide where.

If asked

Is it production-ready on servers? It is being evaluated, not declared a default. Treat it as a credible option to benchmark against EEVDF for your own workload.
Why would a gaming scheduler help a server? Both care about who is on the critical path; wake-up frequency identifies that without knowing anything about the application.
Does LAVD schedule GPU work? No. The GPU is the thing being starved or fed; the scheduling decisions are all CPU-side.

謝謝COSCUP 2026Questions

Thank you

Read the source — main.bpf.c opens with a 180-line design document written by the person who built it.

Project

github.com/sched-ext/scx

Kernel docs

Documentation/scheduler/sched-ext.rst

scx_lavd author

Changwoo Min · Igalia
sponsored by Valve

Presented by Gavin Guo · Igalia O index · ← → navigate · T theme scx_lavd · ~12,100 lines · 904 commits