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. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html