On Tue, Nov 25, 2025 at 10:49 AM Tomas Glozar <[email protected]> wrote: > > po 3. 11. 2025 v 15:45 odesílatel Wander Lairson Costa > <[email protected]> napsal: > > > > > > Executing additional BPF code on latency threshold overflow allows doing > > > doing low-latency and in-kernel troubleshooting of the cause of the > > > > typo: double "doing" > > > > Thanks, I'll fix that :) > > > > --- a/tools/tracing/rtla/src/timerlat.c > > > +++ b/tools/tracing/rtla/src/timerlat.c > > > @@ -48,6 +48,17 @@ timerlat_apply_config(struct osnoise_tool *tool, > > > struct timerlat_params *params) > > > } > > > } > > > > > > + /* Check if BPF action program is requested but BPF is not > > > available */ > > > + if (params->bpf_action_program) { > > > + if (params->mode == TRACING_MODE_TRACEFS) { > > > + err_msg("BPF actions are not supported in > > > tracefs-only mode\n"); > > > > I would just emit a warning to the user and proceed ignoring the bpf action > > argument. > > > > I believe if the user explicitly requests BPF actions to be used, > measurement should not proceed without the action. Imagine someone > setting --bpf-action in an automated test, expecting it to report > something. But the action never fires, because they do not notice they > are running an old kernel that does not support this. > > The user can always restart/reconfigure RTLA to skip the option. >
I was thinking in a more interactive debug session where you go back and forth with little changes in the command line. But you have a good point. > Tomas >
