When a sched_ext scheduler is loaded, depending on the configuration, it
can handle also fair tasks, however it isn't trivial to understand if a
certain task is currently handled by fair or ext outside of scheduler
code. This can be a problem when writing verification or observability
tools like RV monitors.

Export a task_is_scx_enabled() to allow quick classification by using
the scx state SCX_TASK_ENABLED.

To: Tejun Heo <tj@kernel.org>
To: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
---
 include/linux/sched/ext.h | 2 ++
 kernel/sched/ext.c        | 8 ++++++++
 2 files changed, 10 insertions(+)

diff --git a/include/linux/sched/ext.h b/include/linux/sched/ext.h
index bcb962d5ee7d..68e5aff95159 100644
--- a/include/linux/sched/ext.h
+++ b/include/linux/sched/ext.h
@@ -232,6 +232,7 @@ void print_scx_info(const char *log_lvl, struct task_struct *p);
 void scx_softlockup(u32 dur_s);
 bool scx_hardlockup(int cpu);
 bool scx_rcu_cpu_stall(void);
+bool task_is_scx_enabled(struct task_struct *p);
 
 #else	/* !CONFIG_SCHED_CLASS_EXT */
 
@@ -240,6 +241,7 @@ static inline void print_scx_info(const char *log_lvl, struct task_struct *p) {}
 static inline void scx_softlockup(u32 dur_s) {}
 static inline bool scx_hardlockup(int cpu) { return false; }
 static inline bool scx_rcu_cpu_stall(void) { return false; }
+static inline bool task_is_scx_enabled(struct task_struct *p) { return false; }
 
 #endif	/* CONFIG_SCHED_CLASS_EXT */
 
diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 62b1f3ac5630..1e48bc3cde15 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -3772,6 +3772,14 @@ bool task_should_scx(int policy)
 	return policy == SCHED_EXT;
 }
 
+/*
+ * Used by verification/observability tools like RV monitors.
+ */
+bool task_is_scx_enabled(struct task_struct *p)
+{
+	return scx_get_task_state(p) == SCX_TASK_ENABLED;
+}
+
 bool scx_allow_ttwu_queue(const struct task_struct *p)
 {
 	struct scx_sched *sch;
-- 
2.53.0

On Wed, Feb 25, 2026 at 10:51:20AM +0100, Gabriele Monaco wrote:
> When a sched_ext scheduler is loaded, depending on the configuration, it
> can handle also fair tasks, however it isn't trivial to understand if a
> certain task is currently handled by fair or ext outside of scheduler
> code. This can be a problem when writing verification or observability
> tools like RV monitors.
> 
> 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.

Thanks.

-- 
tejun

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:
> > When a sched_ext scheduler is loaded, depending on the configuration, it
> > can handle also fair tasks, however it isn't trivial to understand if a
> > certain task is currently handled by fair or ext outside of scheduler
> > code. This can be a problem when writing verification or observability
> > tools like RV monitors.
> > 
> > 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.

Mmh, right, thanks for the pointer!

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.

Thanks,
Gabriele

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:
> > > When a sched_ext scheduler is loaded, depending on the configuration, it
> > > can handle also fair tasks, however it isn't trivial to understand if a
> > > certain task is currently handled by fair or ext outside of scheduler
> > > code. This can be a problem when writing verification or observability
> > > tools like RV monitors.
> > > 
> > > 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.
> 
> Mmh, right, thanks for the pointer!
> 
> 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.

Thanks.

-- 
tejun

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

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?

Thanks.

-- 
tejun

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?

Thanks,
Gabriele

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

2026-02-26T17:54:35Z Tejun Heo <tj@kernel.org>:
> 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.

Yeah you got a gist of it, essentially RV would be running from the tracepoint contexts, so in this specific scenario it would be synchronised with the scheduler.

Grabbing a pointer via kallsyms and comparing that will do exactly the same job, just a bit more "unofficially".

I can do that if you think such an "official" function won't really be useful. Indeed if that function wouldn't make sense without the rq lock, tracepoints are probably the only valid use case..

Thanks,
Gabriele