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 <gmon...@redhat.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.
