Re: [PATCH v6 14/16] sched_ext: Export task_is_scx_enabled() for verification

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Feb 26, 2026 at 04:25:59PM +0000, Gabriele Monaco wrote:
> 2026-02-26T15:48:11Z Tejun Heo <tj@kernel.org>:
> 
> > On Thu, Feb 26, 2026 at 04:42:34PM +0100, Gabriele Monaco wrote:
> >> 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.
> >
> > Don't you just need the sched_class pointer? Can't you get that from
> > kallsyms?
> 
> Yes that pointer would do. Do you mean getting it in a task_on_scx() reimplementation I would just use in RV?
> I could do that but I was looking for a more standard solution.
> While very likely the pointer to the class and the class field are here to stay, having a function like task_on_scx() directly available in include/linux/sched/ext.h is less error prone and future observability tools might need it too.
> 
> But let's rewind it a bit, if it is a big issue not to have it inlined (which probably isn't), we could just go on with something like _task_on_scx() (inlined, for the scheduler code) and task_on_scx() for other users. Wouldn't that be acceptable?

So, I don't know how rv works (searched a bit just now) but from kernel's
POV, it seems to look mostly like an additional tracing framework, and
testing p->sched_class against exported pointer value seems like a good fit
for the use case, no? It's not like task_on_scx() or state testing is going
to give you a "better" result anyway and it's actually rather confusing to
use them outside scheduler proper as these are expected to be used while the
task's rq lock is held. I don't think rv wants to (or even can) synchronize
against scheduler internals. Using external observability mechanism seems
like the better fit here.

Thanks.

-- 
tejun