K Prateek Nayak <[email protected]> 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
