Re: [PATCH 4/5] sched: Add rt task enqueue/dequeue trace points

[K Prateek Nayak <kprateek.nayak@amd.com>]

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:
>> 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