st 12. 11. 2025 v 16:25 odesÃlatel Crystal Wood <[email protected]> napsal:
>
> Dump the saved IRQ stack trace regardless of whether the event was
> THREAD_CONTEXT or THREAD_URET.
>
> In the uret case, the latency presumably had not yet crossed the
> threshold at IRQ time (or else it would have dumped the stack at thread
> wakeup time, unless we're racing with a change to the threshold), but it
> may have at least contributed -- and this is possible with THREAD_CONTEXT
> as well.
>
> In any case, it helps with writing reliable rtla tests if we always get
> a stack trace on a threshold event.
>
Thank you. The omitting of dumping stack in the uret part of
timerlat_fd_read() looks like a bug to me, I don't see any reason for
it being done for thread latency but not for uret latency, especially
considering the existence of the -a option. Without the patch, -a
behaves differently with kernel and user threads - with kernel
threads, it will always dump the stack on stop tracing if possible,
but with user threads, it will only dump it if the thread latency is
over the threshold.
The help message says:
-s/--stack us: save the stack trace at the IRQ if a thread latency
is higher than the argument in us
but just like in the case of [1], the current behavior (without the
patch) is not natural and no user is going to expect it. (Yes, the
documentation needs updating...)
Compare rtla -a behavior without the patch (auto-analysis without stack):
$ rtla timerlat hist -a 20 --warm-up 2 -c 1
...
max: 3 18 30
timerlat hit stop tracing
## CPU 1 hit stop tracing, analyzing it ##
IRQ handler delay: 0.00 us (0.00 %)
IRQ latency: 3.73 us
Timerlat IRQ duration: 10.66 us (35.39 %)
Blocking thread: 2.94 us (9.77 %)
swapper/1:0 2.94 us
------------------------------------------------------------------------
Thread latency: 30.11 us (100%)
with the behavior with the patch (auto-analysis with stack):
$ rtla timerlat hist -a 20 --warm-up 2 -c 1
...
max: 4 19 23
timerlat hit stop tracing
## CPU 1 hit stop tracing, analyzing it ##
IRQ handler delay: 0.00 us (0.00 %)
IRQ latency: 4.10 us
Timerlat IRQ duration: 9.65
us (41.79 %)
Blocking thread: 4.58
us (19.81 %)
swapper/1:0 4.58 us
Blocking thread stack trace
-> timerlat_irq
...
-> common_startup_64
------------------------------------------------------------------------
Thread latency: 23.11 us (100%)
Tested-by: Tomas Glozar <[email protected]>
Reviewed-by: Tomas Glozar <[email protected]>
[1]
https://lore.kernel.org/linux-trace-kernel/[email protected]/
Tomas
