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

[Nam Cao <namcao@linutronix.de>]

K Prateek Nayak <kprateek.nayak@amd.com> writes:

> Hello Gabriele,
>
> On 8/1/2025 4:34 PM, Gabriele Monaco wrote:
>> 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!

No trouble at all, it was all helpful comments.

I agree with Gabriele, it is not important right now, so I will stick to
the latest diff I sent. Leaving it to the poor soul who needs this for
fair tasks to figure it out (which will probably be future me).

Thanks for the insights,
Nam