Hello Gabriele,

On 8/1/2025 4:34 PM, Gabriele Monaco wrote:

On Fri, 2025-08-01 at 15:26 +0530, K Prateek Nayak wrote:

quoted

There are a few more cases with delayed dequeue:

1. A delayed task can be reenqueued before it is completely dequeued
and
   will lead to a enqueue -> enqueue transition if we don't trace the
   first dequeue.

2. There are cases in set_user_nice() and __sched_setscheduler()
where
   a delayed task is dequeued in delayed state and be put back in the
   cfs_rq in delayed state - an attempt to handle 1. can trip this.

Best I could think of is the below diff on top of your suggestion
where
a "delayed -> reenqueue" is skipped but the case 2. is captures in
case
one needs to inspect some properties from set_user_nice() /
__sched_setscheduler():

(only build tested on top of the diff you had pasted)

Hello Prateek,

thanks for the comments, this looks much more convoluted than I would
have expected.
As Nam pointed out, currently RV is not going to rely on those events
for fair tasks (existing monitors are fine with tracepoints like
wakeup/set_state/switch).

For the time being it might be better just add the tracepoints in the
RT enqueue/dequeue (the only needed for this series) and not complicate
things.

At most we may want to keep tracepoint names general, allowing the
tracing call to be added later to other locations (or moved to a
general one) without changing too much, besides existing users.
And perhaps a comment saying the tracepoints are currently only
supported on RT would do.

Most of my comments was just thinking out loud around fair tasks being
delayed on the dequeue path. If RV filters out RT tasks and the use-case
one concerns them, then Nam's suggestion is good.

I was just being cautious of folks expecting a "enqueued <--> dequeued"
transition for *all* tasks and finding it doesn't hold after delayed
dequeue. Since these are internal tracepoints, I'm sure folks using them
with RV would do their due diligence when testing these monitors before
deployment.

Anyway, that's your call Nam, I'm fine with your initial proposal as
well, unless some scheduler guys complain.

I would be happy to help test alternate approaches if others have
concerns around delayed dequeue but for all other cases, Nam's approach
looks good. Sorry if my paranoia caused you folks any trouble!

-- 
Thanks and Regards,
Prateek