Hello, On Thu, Feb 26, 2026 at 04:25:59PM +0000, Gabriele Monaco wrote: > 2026-02-26T15:48:11Z Tejun Heo <[email protected]>: > > > 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
