linux-kernel - Re: [PATCH 4/5] sched: Add rt 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250730151818.7RemAREO@linutronix.de>
Date: Wed, 30 Jul 2025 17:18:18 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	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>
Subject: Re: [PATCH 4/5] sched: Add rt task enqueue/dequeue trace points

On Wed, Jul 30, 2025 at 03:53:14PM +0200, Gabriele Monaco wrote:
> On Wed, 2025-07-30 at 14:45 +0200, Nam Cao wrote:
> > Add trace points into enqueue_task_rt() and dequeue_task_rt(). They
> > are useful to implement RV monitor which validates RT scheduling.
> > 
> 
> I get it's much simpler this way, but is it that different to follow
> the task's existing tracepoints?
> 
> * task going to sleep (switch:prev_state != RUNNING) is dequeued
> * task waking up is enqueued
> * changing the tasks's policy (setpolicy and setattr syscalls) should
> enqueue/dequeue as well
> 
> This is more thinking out loud, but I'm doing right now something
> rather similar with the deadline tasks and this seems reasonable, at
> least on paper.
> 
> What do you think?

I think more or less the same. The fewer tracepoints, the better. But the
monitor is way more obvious this way.

Let me see how hard it is to use the existing tracepoints...

Nam