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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <47c67022-427c-4c24-8dcf-a3721f8c5bdd@amd.com>
Date: Thu, 21 Aug 2025 14:13:54 +0530
From: K Prateek Nayak <kprateek.nayak@....com>
To: Nam Cao <namcao@...utronix.de>, Peter Zijlstra <peterz@...radead.org>
CC: Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
	<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Gabriele Monaco <gmonaco@...hat.com>, <linux-trace-kernel@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Juri Lelli
	<juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall <bsegall@...gle.com>,
	Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, "Phil
 Auld" <pauld@...hat.com>
Subject: Re: [PATCH v2 4/5] sched: Add task enqueue/dequeue trace points

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@...hat.com>, who seems to care about the
> nr_running tracepoints.
> 
> Nam

-- 
Thanks and Regards,
Prateek