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

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

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/20250715071658.267-1-ziqianlu@bytedance.com/
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 <pauld@redhat.com>, who seems to care about the
> nr_running tracepoints.
> 
> Nam

-- 
Thanks and Regards,
Prateek