sched_ext and proxy execution set to share one Linux kernel

Linux distributions that want a single kernel binary may soon stop choosing between two scheduler features that have been mutually exclusive at build time. Andrea Righi has posted a fourteenth revision of work, building on earlier efforts by John Stultz, that lets proxy execution and sched_ext run together, aimed at the sched_ext tree for the 7.4 cycle.

Proxy execution lets a task blocked on a mutex donate its scheduling context to the lock owner, so the owner can run while the waiter stays eligible on the runqueue. sched_ext lets custom BPF programs replace the CPU scheduler. Until now the two could not be enabled in the same kernel: a proxy handoff can put a task on the CPU that the BPF side never dispatched, leaving dispatch queues, virtual time, and “who is running” helpers out of sync with what the core actually executes.

Righi’s design turns support into an optional per-scheduler contract. A BPF scheduler that sets SCX_OPS_ENQ_BLOCKED keeps mutex-blocked donors runnable and receives them on enqueue with a blocked flag, so it controls whether, where, and in what order each donor is dispatched. The core then walks the owner chain and, when needed, migrates the donor’s scheduling context before running the owner. Schedulers that omit the flag keep the old behavior and block those tasks normally.

The series also hardens ownership changes, running-session tracking across proxy switches, and placement races that could otherwise migrate an active execution context. Selftests exercise priority-inversion cases on same-CPU and cross-CPU layouts with the option on and off. The practical payoff is straightforward: one kernel image can expose both features, and operators choose at runtime whether a given BPF scheduler participates in proxy donors.