linux-kernel - Re: [RFC PATCH 14/17] sched: Add deadline tracepoints

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: <20250819101244.GF4067720@noisy.programming.kicks-ass.net>
Date: Tue, 19 Aug 2025 12:12:44 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Gabriele Monaco <gmonaco@...hat.com>, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Ingo Molnar <mingo@...hat.com>, linux-trace-kernel@...r.kernel.org,
	Nam Cao <namcao@...utronix.de>, Tomas Glozar <tglozar@...hat.com>,
	Juri Lelli <jlelli@...hat.com>,
	Clark Williams <williams@...hat.com>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [RFC PATCH 14/17] sched: Add deadline tracepoints

On Tue, Aug 19, 2025 at 11:56:57AM +0200, Juri Lelli wrote:
> Hi!
> 
> On 14/08/25 17:08, Gabriele Monaco wrote:
> > Add the following tracepoints:
> > 
> > * sched_dl_throttle(dl):
> >     Called when a deadline entity is throttled
> > * sched_dl_replenish(dl):
> >     Called when a deadline entity's runtime is replenished
> > * sched_dl_server_start(dl):
> >     Called when a deadline server is started
> > * sched_dl_server_stop(dl, hard):
> >     Called when a deadline server is stopped (hard) or put to idle
> >     waiting for the next period (!hard)
> > 
> > Those tracepoints can be useful to validate the deadline scheduler with
> > RV and are not exported to tracefs.
> > 
> > Signed-off-by: Gabriele Monaco <gmonaco@...hat.com>
> > ---
> >  include/trace/events/sched.h | 55 ++++++++++++++++++++++++++++++++++++
> >  kernel/sched/deadline.c      |  8 ++++++
> >  2 files changed, 63 insertions(+)
> > 
> > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> > index 7b2645b50e78..f34cc1dc4a13 100644
> > --- a/include/trace/events/sched.h
> > +++ b/include/trace/events/sched.h
> > @@ -609,6 +609,45 @@ TRACE_EVENT(sched_pi_setprio,
> >  			__entry->oldprio, __entry->newprio)
> >  );
> >  
> > +/*
> > +DECLARE_EVENT_CLASS(sched_dl_template,
> > +
> > +	TP_PROTO(struct sched_dl_entity *dl),
> > +
> > +	TP_ARGS(dl),
> > +
> > +	TP_STRUCT__entry(
> > +		__field(  struct task_struct *,	tsk		)
> > +		__string( comm,		dl->dl_server ? "server" : container_of(dl, struct task_struct, dl)->comm	)
> > +		__field(  pid_t,	pid		)
> > +		__field(  s64,		runtime		)
> > +		__field(  u64,		deadline	)
> > +		__field(  int,		dl_yielded	)
> 
> I wonder if, while we are at it, we want to print all the other fields
> as well (they might turn out to be useful). That would be
> 
>  .:: static (easier to retrieve with just a trace)
>  - dl_runtime
>  - dl_deadline
>  - dl_period
> 
>  .:: behaviour (RECLAIM)
>  - flags
> 
>  .:: state
>  - dl_ bool flags in addition to dl_yielded

All these things are used as _tp(). That means they don't have trace
buffer entries ever, why fill out fields?


> > +	),
> > +
> > +	TP_fast_assign(
> > +		__assign_str(comm);
> > +		__entry->pid		= dl->dl_server ? -1 : container_of(dl, struct task_struct, dl)->pid;
> > +		__entry->runtime	= dl->runtime;
> > +		__entry->deadline	= dl->deadline;
> > +		__entry->dl_yielded	= dl->dl_yielded;
> > +	),
> > +
> > +	TP_printk("comm=%s pid=%d runtime=%lld deadline=%lld yielded=%d",
>                                                         ^^^
> 							llu ?
> 
> > +			__get_str(comm), __entry->pid,
> > +			__entry->runtime, __entry->deadline,
> > +			__entry->dl_yielded)
> > +);
> 
> ...
> 
> > @@ -1482,6 +1486,7 @@ static void update_curr_dl_se(struct rq *rq, struct sched_dl_entity *dl_se, s64
> >  
> >  throttle:
> >  	if (dl_runtime_exceeded(dl_se) || dl_se->dl_yielded) {
> > +		trace_sched_dl_throttle_tp(dl_se);
> >  		dl_se->dl_throttled = 1;
> 
> I believe we also need to trace the dl_check_constrained_dl() throttle,
> please take a look.
> 
> Also - we discussed this point a little already offline - but I still
> wonder if we have to do anything special for dl-server defer. Those
> entities are started as throttled until 0-lag, so maybe we should still
> trace them explicitly as so?
> 
> In addition, since it's related, maybe we should do something about
> sched_switch event, that is currently not aware of deadlines, runtimes,
> etc.

As per the whole _tp() thing, you can attach to the actual
sched_switch tracepoint with a module and read whatever you want.