Hello, On Thu, 2026-02-26 at 05:22 -1000, Tejun Heo wrote: > Hello, > > On Thu, Feb 26, 2026 at 08:10:52AM +0100, Gabriele Monaco wrote: > > On Wed, 2026-02-25 at 07:08 -1000, Tejun Heo wrote: > > > On Wed, Feb 25, 2026 at 10:51:20AM +0100, Gabriele Monaco wrote: > > > > Export a task_is_scx_enabled() to allow quick classification by using > > > > the scx state SCX_TASK_ENABLED. > > > > > > This test already exists - task_on_scx(). Please feel free to move that > > > out to include/linux/sched/ext.h. > > > > I see task_on_scx() is used in what looks like some sched core hot paths ( > > pick_next_task() -> prio_less()), but I presume not inlining it isn't a big > > issue. > > I mean, you can always export what task_on_scx() accesses.
I'm not sure what the cleanest thing is here task_on_scx() is scx_enabled() && p->sched_class == &ext_sched_class scx_enabled() might as well be exported (together with its static key), but I'm not sure exporting the sched_class is the right thing, since all those scheduler things are quite private. On the other hand, task_is_scx_enabled() (added in this patch) is scx_get_task_state(p) == SCX_TASK_ENABLED and scx_get_task_state() is (p->scx.flags & SCX_TASK_STATE_MASK) >> SCX_TASK_STATE_SHIFT those are pretty much already exported. If those are really equivalent, wouldn't it be simpler to export scx_get_task_state() and use that in an exported (still inlined) version of task_on_scx() ? If you think exporting a sched_class is just fine I'd follow on with your suggestion without bothering, though. Thanks, Gabriele
