On Wed, Jul 16, 2025 at 03:05:50PM +0200, Gabriele Monaco wrote: > On Wed, 2025-07-16 at 14:41 +0200, Peter Zijlstra wrote: > > On Wed, Jul 16, 2025 at 02:18:28PM +0200, Gabriele Monaco wrote: > > > On Wed, 2025-07-16 at 13:50 +0200, Peter Zijlstra wrote: > > > > On Tue, Jul 15, 2025 at 09:14:18AM +0200, Gabriele Monaco wrote: > > > > > Currently, the userspace RV tool skips trace events triggered by the > > > > > RV > > > > > tool itself, this can be changed by passing the parameter -s, which > > > > > sets the variable config_my_pid to 0 (instead of the tool's PID). The > > > > > current condition for per-task monitors (config_has_id) does not check > > > > > that config_my_pid isn't 0 to skip. In case we pass -s, we show events > > > > > triggered by RV but don't show those triggered by idle (PID 0). > > > > > > > > The distinction between !my_pid and has_id is that you can in fact trace > > > > pid-0 if you want? > > > > > > > Yes pretty much, no flag is meant to skip events from pid-0. > > > > > > > - if (config_has_id && (config_my_pid == id)) > > > > > + if (config_my_pid && config_has_id && (config_my_pid == id)) > > > > But should we then not write: > > > > if (config_has_id && (config_my_pid == id)) > > Sorry, got a bit confused, I flipped the two while describing: > * -s shows traces from RV but skips from pid-0 (unintended) > * omitting -s skips events from RV (correct) > > If we are running a per-task monitor config_has_id is always true, we pass -s, > which makes config_my_pid = 0 (intended /not/ to skip RV). > Now when we are about to trace an event from idle (id=0), we skip it, although > we really shouldn't. > That's why we also needs to check for config_my_pid not being 0. > > Does it make sense?
Sorta, but would it not make sense to use has_pid := -1 for the invalid case, instead of 0, which is a valid pid?
