rtla/timerlat: Do not set params->user_workload with -U
authorTomas Glozar <tglozar@redhat.com>
Mon, 21 Oct 2024 12:31:40 +0000 (14:31 +0200)
committerSteven Rostedt (Google) <rostedt@goodmis.org>
Tue, 19 Nov 2024 13:56:59 +0000 (08:56 -0500)
commitfcbc60d7dc4b125c8de130aa1512e5d20726c06e
treef63b8ff66e1d1e08606171b63fef2031d080dada
parent13216486e3ede30d6910a22e0e15988b7016366b
rtla/timerlat: Do not set params->user_workload with -U

Since commit fb9e90a67ee9 ("rtla/timerlat: Make user-space threads
the default"), rtla-timerlat has been defaulting to
params->user_workload if neither that or params->kernel_workload is set.
This has unintentionally made -U, which sets only params->user_hist/top
but not params->user_workload, to behave like -u unless -k is set,
preventing the user from running a custom workload.

Example:
$ rtla timerlat hist -U -c 0 &
[1] 7413
$ python sample/timerlat_load.py 0
Error opening timerlat fd, did you run timerlat -U?
$ ps | grep timerlatu
7415 pts/4    00:00:00 timerlatu/0

Fix the issue by checking for params->user_top/hist instead of
params->user_workload when setting default thread mode.

Link: https://lore.kernel.org/20241021123140.14652-1-tglozar@redhat.com
Fixes: fb9e90a67ee9 ("rtla/timerlat: Make user-space threads the default")
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
tools/tracing/rtla/src/timerlat_hist.c
tools/tracing/rtla/src/timerlat_top.c