trace/latency-hist: Consider new argument when probing the sched_switch tracer

trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Carsten Emde]

Hi Thomas & Sebastian,

The sched_switch tracer has got a new argument. Fix the latency tracer
accordingly.

Thanks,
    -Carsten.

Signed-off-by: Carsten Emde <C.Emde@osadl.org>

---
 kernel/trace/latency_hist.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-4.4.0-rc6-rt1/kernel/trace/latency_hist.c
===================================================================
--- linux-4.4.0-rc6-rt1.orig/kernel/trace/latency_hist.c
+++ linux-4.4.0-rc6-rt1/kernel/trace/latency_hist.c
@@ -117,7 +117,7 @@ static char *wakeup_latency_hist_dir_sha
 static notrace void probe_wakeup_latency_hist_start(void *v,
 	struct task_struct *p);
 static notrace void probe_wakeup_latency_hist_stop(void *v,
-	struct task_struct *prev, struct task_struct *next);
+	bool preempt, struct task_struct *prev, struct task_struct *next);
 static notrace void probe_sched_migrate_task(void *,
 	struct task_struct *task, int cpu);
 static struct enable_data wakeup_latency_enabled_data = {
@@ -907,7 +907,7 @@ out:
 }

 static notrace void probe_wakeup_latency_hist_stop(void *v,
-	struct task_struct *prev, struct task_struct *next)
+	bool preempt, struct task_struct *prev, struct task_struct *next)
 {
 	unsigned long flags;
 	int cpu = task_cpu(next);

Re: trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Sebastian Andrzej Siewior]

* Carsten Emde | 2016-01-05 10:21:59 [+0100]:

>Hi Thomas & Sebastian,
Hi Carsten,

>The sched_switch tracer has got a new argument. Fix the latency tracer
>accordingly.
>
>Thanks,
>    -Carsten.
>
>Signed-off-by: Carsten Emde <C.Emde@osadl.org>

Thanks.
Is it somehow possible to detect this kind of bugs at compile time? Is
there an easy way to do this?
What is blocking the latency-hist tracer from entering mainline?

Sebastian

Re: trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Steven Rostedt]

On Wed, 13 Jan 2016 16:45:26 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:


> Is it somehow possible to detect this kind of bugs at compile time? Is
> there an easy way to do this?

There should have been a warning. Wasn't there one?

> What is blocking the latency-hist tracer from entering mainline?

Has it been submitted. Like lots of things in -rt, it just takes the
effort of pushing out an RFC for inclusion.

-- Steve

Re: trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Sebastian Andrzej Siewior]

On 01/13/2016 04:51 PM, Steven Rostedt wrote:
> On Wed, 13 Jan 2016 16:45:26 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
>> Is it somehow possible to detect this kind of bugs at compile time? Is
>> there an easy way to do this?
> 
> There should have been a warning. Wasn't there one?

Sorry, my bad. I didn't enable it… Yes, there is one.

>> What is blocking the latency-hist tracer from entering mainline?
> 
> Has it been submitted. Like lots of things in -rt, it just takes the
> effort of pushing out an RFC for inclusion.

Not that I recall. But this means that there is nothing specific that
you are aware of that needs to be changed before RFC.

So, Carsten do you mind taking the latency-hist patch and submitting it
as RFC for upstream inclusion?

> -- Steve
> 
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Carsten Emde]

Hi Sebastian, hi Steven,

>>> [..] What is blocking the latency-hist tracer from entering
>>> mainline?
>> 
>> Has it been submitted. Like lots of things in -rt, it just takes
>> the effort of pushing out an RFC for inclusion.
> 
> Not that I recall. But this means that there is nothing specific
> that you are aware of that needs to be changed before RFC.
> 
> So, Carsten do you mind taking the latency-hist patch and submitting
> it as RFC for upstream inclusion?
There are two things here:

1. The sum of the timer latency and the wakeup latency does not completely
cover the total preemption latency as, for example, determined by cyclictest.
The time of the context switch until the new task resumes execution at the
next line after the wait instruction is still lacking. I wrote a related
patch sometime ago that is working since then in numerous farm systems -
but I never posted the patch of this switchtime histogram, because someone
said that we first need to re-engineer the histogram code in general.
Nevertheless, I used the opportunity of your posting to submit the patch in
a separate thread so you can have a look. As a bonus, the name of the
delayed system call that caused the highest latency until then is provided
when the switchtime histogram is enabled - this may or may not be helpful
when searching for the source of a latency.

2. The idea behind re-engineering the histogram code someone proposed several
years ago is to create a general framework that can be used throughout the
kernel (or even from user space through a dedicated tracer interface) for any
variable the frequency distribution of which is of interest and that would
best be monitored in form of a frequency histogram - such as a latency
distribution. The various latency tracers would then serve as a practical
example of how to use this fancy new framework. I let you guess why this
re-engineering did not yet happen.

So the question is whether you still encourage me to write the RFC for
upstream inclusion of the current code after some polishing - maybe, in the
hope that someone will come up with the framework during RFC discussion -
or we better wait, since writing an RFC for hopeless code really doesn't
make sense.

Thanks,
	-Carsten.

Re: trace/latency-hist: Consider new argument when probing the sched_switch tracer

[Steven Rostedt]

On Fri, 15 Jan 2016 12:30:55 +0100
Carsten Emde <C.Emde@osadl.org> wrote:


> So the question is whether you still encourage me to write the RFC for
> upstream inclusion of the current code after some polishing - maybe, in the
> hope that someone will come up with the framework during RFC discussion -
> or we better wait, since writing an RFC for hopeless code really doesn't
> make sense.

Note, the latency measurement code is basically the last code that is
practically untouched from what was in the original latency-tracer code
from the -rt patch. It's been on my todo list to update it for some
time. There's a few things lacking with it. I want to improve that.

Perhaps this should be done before pushing in a histogram
infrastructure on top of it. I'll move this up on my priority list.

-- Steve