Hello Nam, On 8/21/2025 12:35 PM, Nam Cao wrote: >>> How about something like: >>> >>> dequeue_task(): >>> ... >>> ret = p->sched_class->dequeue_task(rq, p, flags); >>> if (trace_dequeue_task_p_enabled() && !(flags & DEQUEUE_SLEEP)) >>> __trace_dequeue_task_tp(rq->cpu, p); >>> return ret; >>> >>> >>> __block_task(): >>> trace_dequeue_task_tp(rq->cpu, p); >>> ... >>> >>> >>> Specifically, only DEQUEUE_SLEEP is allowed to fail, and DEQUEUE_SLEEP >>> will eventually cause __block_task() to be called, either directly, or >>> delayed. >> >> If you extend the tracepoint with the sleep state, you can probably >> remove the nr_running tracepoints. Esp. once we get this new throttle >> stuff sorted. > > Sorry, I'm a bit out of depth here. Can you elaborate? > > By "sleep state" do you mean (flags & DEQUEUE_SLEEP)? The nr_running > tracepoints are not hit if the task is throttled, while these new > tracepoints are hit. How does the sleep state help with this difference?
Once we have per-task throttling being discussed in https://lore.kernel.org/lkml/[email protected]/ throttled tasks will do a dequeue_task_fair(rq, p, DEQUEUE_SLEEP | DEQUEUE_THROTTLE); and remove themselves from the runqueue but they won't hit block_task(). To preserve current throttle behavior, I don't think per-task throttle should call dequeue_task() directly since it does a bunch more stuff with core-sched dequeue, psi, uclamp, etc or maybe it is fine to do that now with per-task throttling? Peter, what do you think? If we don't what to do all that stuff in the throttle path, adding to Peter's suggestion, perhaps we can have a wrapper like: int __dequeue_task(rq, p, flags) int ret = p->sched_class->dequeue_task(rq, p, flags); if (trace_dequeue_task_p_enabled() && !((flags & (DEQUEUE_SLEEP | DEQUEUE_THROTTLE)) == DEQUEUE_SLEEP)) __trace_dequeue_task_tp(rq->cpu, p); return ret; and then per-task throttle can just call __dequeue_task() instead. I'll let Peter chime in with his thoughts. > > Also +Cc Phil Auld <[email protected]>, who seems to care about the > nr_running tracepoints. > > Nam -- Thanks and Regards, Prateek
