On Wed, 2025-07-30 at 17:18 +0200, Nam Cao wrote: > On Wed, Jul 30, 2025 at 03:53:14PM +0200, Gabriele Monaco wrote: > > On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote: > > > Add trace points into enqueue_task_rt() and dequeue_task_rt(). > > > They > > > are useful to implement RV monitor which validates RT scheduling. > > > > > > > I get it's much simpler this way, but is it that different to > > follow > > the task's existing tracepoints? > > > > * task going to sleep (switch:prev_state != RUNNING) is dequeued > > * task waking up is enqueued > > * changing the tasks's policy (setpolicy and setattr syscalls) > > should > > enqueue/dequeue as well > > > > This is more thinking out loud, but I'm doing right now something > > rather similar with the deadline tasks and this seems reasonable, > > at > > least on paper. > > > > What do you think? > > I think more or less the same. The fewer tracepoints, the better. But > the > monitor is way more obvious this way. > > Let me see how hard it is to use the existing tracepoints...
Well, thinking about it again, these tracepoints might simplify things considerably when tasks change policy.. Syscalls may fail, for that you could register to sys_exit and check the return value, but at that point the policy changed already, so you cannot tell if it's a relevant event or not (e.g. same policy). Also sched_setscheduler_nocheck would be out of the picture here, not sure how recurrent that is though (and might not matter if you only focus on userspace tasks). If you go down the route of adding tracepoints, why not have other classes benefit too? I believe calling them from the enqueue_task / dequeue_task in sched/core.c would allow you to easily filter out by policy anyway (haven't tested). Thanks, Gabriele
