Proxy execution and sched_ext move toward coexistence

Andrea Righi has posted a thirteenth revision of work that would let the Linux kernel build and run proxy execution together with sched_ext, removing a long-standing mutual exclusion between the two scheduler features.

Proxy execution lets a task blocked on a mutex donate its scheduling context to the lock owner, so the owner can run under the waiter’s priority and runtime budget while the waiter stays eligible on the runqueue. sched_ext lets BPF programs implement custom CPU schedulers. 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 scheduler never dispatched, leaving dispatch queues, vtime, and “who is current” state out of sync with what helpers and kfuncs expect.

The series, based on earlier work by John Stultz, treats support as an optional per-scheduler capability. A BPF scheduler that sets SCX_OPS_ENQ_BLOCKED keeps mutex-blocked donors runnable, receives them through enqueue with a blocked flag, and decides whether and where to place them. 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 blocking behavior.

That matters for distributors and anyone who ships one kernel image and wants features selectable at runtime rather than at build time. The series also includes preparatory core fixes around donor reset ordering, tick and bandwidth checks under a retained donor, and migration-disabled warnings when only a blocked scheduling context moves.

Tejun Heo said the work looked ready to merge and iterate in tree from the sched_ext side, aside from cleanup nits. Peter Zijlstra offered a cursory positive take and has been reviewing individual patches, raising questions on donor versus current class combinations, class-change handling of retained proxy state, and some wakeup-path flags. Iteration on those points continues on the linux-kernel list.