[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180524083754.GD12198@hirez.programming.kicks-ass.net>
Date: Thu, 24 May 2018 10:37:54 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] sched,tracing: Correct trace_sched_pi_setprio() for
deboosting
On Thu, May 24, 2018 at 09:44:14AM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-23 19:28:19 [+0200], Peter Zijlstra wrote:
> > On Wed, May 23, 2018 at 04:11:07PM +0200, Sebastian Andrzej Siewior wrote:
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index 092f7c4de903..888df643b99b 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@ -3823,7 +3823,7 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
> > > goto out_unlock;
> > > }
> > >
> > > - trace_sched_pi_setprio(p, pi_task);
> > > + trace_sched_pi_setprio(p, prio);
> I don't see the point in open coding __rt_effective_prio() and
> recomputing the value we already have. I'm a little worried that if
> something happens to `prio' we might miss it and notice later while
> debugging.
> However, if they are reasons like breaking the trace-API for $tools, I
> can update it.
Thing is, with the pi_task as an argument, someone using the tracehook
can actually get the deadline data out, even if the normal 'event' does
not.
Powered by blists - more mailing lists