Stano,
Sure, record everything (trace-cmd record -e all) and analyze the
traces.
Well, the problem is that with record -e all I get 20 ms instead
of 1 ms, so I'd say Mr. Heisenberg laughs at me loudly here ;)
He who laughs last, laughs loudest. Since the entire system slows down,
you may only need to adapt cycles and thresholds accordingly. Tracing is
a very useful tool to identify sources of latencies and has helped a lot
to make Linux RT as good as it is today. As a role of thumb, for
example, we use five times longer cycles when enabling function tracing.
If, for example, the output of
cyclictest -m -M -Sp90 -i100 -d0
most of the time indicates a worst-case latency of about 50 microseconds
but is interspersed with sporadic latencies of more than 500 microseconds,
cyclictest -m -M -Sp90 -i500 -d0 -fb1000
probably will break at the first occurrence of the latency in question
and let you diagnose its origin at the end of the trace output.
-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
