Timerlat auto-analysis:
- Timerlat is reporting thread interference time without thread noise
events occurrence. It was caused because the thread interference variable
was not reset after the analysis of a timerlat activation that did not
hit the threshold.
- The IRQ handler delay is estimated from the delta of the IRQ latency
reported by timerlat, and the timestamp from IRQ handler start event.
If the delta is near-zero, the drift from the external clock and the
trace event and/or the overhead can cause the value to be negative.
If the value is negative, print a zero-delay.
- IRQ handlers happening after the timerlat thread event but before
the stop tracing were being reported as IRQ that happened before the
*current* IRQ occurrence. Ignore Previous IRQ noise in this condition
because they are valid only for the *next* timerlat activation.
Timerlat user-space:
- Timerlat is stopping all user-space thread if a CPU becomes
offline. Do not stop the entire tool if a CPU is/become offline,
but only the thread of the unavailable CPU. Stop the tool only,
if all threads leave because the CPUs become/are offline.
man-pages:
- Fix command line example in timerlat hist man page.
rtla: fix a example in rtla-timerlat-hist.rst
The following error message is reported when running the example in document.
# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms --no-aa
Failed to set timerlat period
Could not apply config
The unit of the period is microsecond, '1ms' cannot be accepted.
usage: [rtla] timerlat hist [-h] [-q] [-d s] [-D] [-n] [-a us] [-p us] [-i us] [-T us] [-s us] ...
...
-p/--period us: timerlat period in us
...
Also fix another minor missleading comment.
Link: https://lore.kernel.org/lkml/20230919133028.697144-1-xiexiuqi@huaweicloud.com
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
1 file changed
