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

[Carsten Emde <C.Emde@osadl.org>]

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.