sched_ext is still experimental and while we're trying to reduce the number of breaking changes, sometimes they're neccessary to fix bugs or improve the usability.
Below are the changes in both the sched_ext kernel tree and the associated commits in this repo.
scx: Rename prep_enable() and cancel_enable(), add exit_task() [Kernel commit / PR] [scx commit]
ops.prep_enable()
is now calledops.init_task()
struct scx_enable_args
is nowstruct scx_init_task_args
ops.enable()
andops.disable()
are now called when a task enters and exits sched_ext respectively. This is the same for when all tasks are using scx, but the callbacks can now be fired multiple times for tasks switching their sched policy.- No longer passing struct
scx_enable_args *args
toops.enable()
.
- No longer passing struct
ops.cancel_enable()
has been removed, andops.exit_task()
(explained below) is invoked in its stead.ops.exit_task()
has been added, and is called exactly once when a task is exiting ifops.init_task()
had been successfully invoked on the task previously (or would have been invoked if the callback was defined).- Called in lieu of
ops.cancel_enable()
as described above - Called with
struct scx_exit_task_args *args
instead ofscx_enable_args *args
.
- Called in lieu of
scx: Add scx_bpf_select_cpu_dfl() kfunc [Kernel commit…Kernel commit, PR] [scx commit]
- The default CPU selection logic operates differently now. We no longer pass
SCX_ENQ_LOCAL
when the default CPU selection has found a core to schedule. Callers can instead usescx_bpf_select_cpu_dfl()
to get the same behavior and then decide whether to direct dispatch or not. - Tasks can now be direct-dispatched from
ops.select_cpu()
.