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: > > On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote: > > > 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? > > > > 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- > >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. > > > > 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
