On Thu, 11 Jun 2015, Mike Galbraith wrote:
> On Wed, 2015-06-10 at 20:59 +0200, Thomas Gleixner wrote:
> Well, trying to do that like so...
>
> trace-cmd record -M 8 -p function -e irq:* -e irq_vectors:local* -e
> timer:hrtimer* -- sleep 1
> ..capture takes much more than a second...
>
> LOC: 248161 226536 42091 38892 Local timer interrupts
> LOC: 248381 226783 42092 38901 Local timer interrupts
> LOC: 248668 227038 42092 38903 Local timer interrupts
> LOC: 248963 227277 42092 38904 Local timer interrupts
> LOC: 249214 227515 42092 38905 Local timer interrupts
> LOC: 249486 227732 42092 38905 Local timer interrupts
> LOC: 249720 227961 42092 38905 Local timer interrupts
>
> ...but more importantly, when it gets cranked up..
>
> homer:~/tmp # trace-cmd report > report
> homer:~/tmp # grep local_timer_entry report|wc -l
> 252
>
> ...it scares the problem away.
Can you try the following, please?
Enable function tracer and hrtimer events manually. Then watch the irq
count on cpu3. If it stalls or becomes slow, then stop the trace with
echo 0 >/sys/kernel/debug/tracing/tracing_on
If the overhead of the function tracer hides the problem, then try just
with hrtimer, sched_switch and irq events.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
