On Fri, 2025-08-01 at 09:58 +0200, Nam Cao wrote:

On Thu, Jul 31, 2025 at 09:47:10AM +0200, Gabriele Monaco wrote:

quoted

On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote:

quoted

Add "real-time scheduling" monitor, which validates that SCHED_RR
and SCHED_FIFO tasks are scheduled before tasks with normal and
extensible scheduling policies

Looks a very interesting monitor!
A few questions:

I assume this works with rt-throttle because it implies a dequeue,
right?
And you probably won't see that without explicit tracepoints..

It does work properly with rt-throttling:
	root@yellow:~# ./rt-loop
	[   74.357730] sched: RT throttling activated
	[   74.357745] rv: rts: 0: violation detected

Looking at rt-throlling code, it does not dequeue tasks, only does
	rt_rq->rt_throttled = 1;
	rt_rq->rt_queued = 0;

so we are fine.

Wait, by /works properly/ you mean it reports a violation. I just
noticed you mention it in the description.

It's reasonable to request RT throttling disabled on sanely configured
RT systems. But throttling is a /valid/ kernel feature, I get you mark
it as /unwanted/ though.

I guess if that's the case, this monitor doesn't belong in the sched
collection because it's meant to validate the kernel behaviour, not its
configuration for a specific purpose (RT).
Isn't it better off with the rtapp ones (which validate the system
configuration to run in an RT scenario).

Does it make sense to you?

quoted

As far as I understand here the monitor would just miss RT tasks
already running but would perfectly enforce the ones starting after
initialisation, right?

Not exactly. What could happen is that:

 - RT task A already running

 - monitor enabled. The monitor isn't aware of task A, therefore it
allows
   sched_switch to switch to non-RT task.

 - RT task B is queued. The monitor now knows at least one RT task is
   enqueued, so it disallows sched_switch to switch to non-RT.

 - RT task A is dequeued. However, the monitor does not differentiate
task
   A and task B, therefore I thinks the only enqueued RT task is now
gone.

 - So now we have task B started after the monitor, but the monitor
does not check it.

The monitor will become accurate once the CPU has no enqueued RT
task, which should happen quite quickly on a sane setup where RT
tasks do not monopoly the CPU.

The monitor could be changed to be accurate from the get-go, by
looking at how many enqueued RT tasks are present. I *think* rt_rq-

quoted

rt_nr_running works. But I think the current implementation is

fine, so not worth thinking too much about it.

Yeah if it's something quickly reached it shouldn't be a problem, also
rt throttle would run in case there's an RT monopoly and you'd see a
violation already.

quoted

Not sure you can do much about it though. (without falling into the
need resched rabbithole I was trying to untangle)

I would need to look into scheduler code, maybe we could check that
the next scheduler tick implies a sched_switch. Another day.

Agree, the monitor looks good for now.
I still want to give it a run when I have a bit more time, besides with
RT throttle, can the monitor really fail on a working system?

Thanks,
Gabriele