On Tue, 2025-04-29 at 14:01 +0200, Nam Cao wrote: > Add a monitor for checking that real-time tasks do not go to sleep in > a > manner that may cause undesirable latency. > > Also change > RV depends on TRACING > to > RV select TRACING > to avoid the following recursive dependency: > > error: recursive dependency detected! > symbol TRACING is selected by PREEMPTIRQ_TRACEPOINTS > symbol PREEMPTIRQ_TRACEPOINTS depends on TRACE_IRQFLAGS > symbol TRACE_IRQFLAGS is selected by RV_MON_SLEEP > symbol RV_MON_SLEEP depends on RV > symbol RV depends on TRACING > > Reviewed-by: Gabriele Monaco <[email protected]> > Signed-off-by: Nam Cao <[email protected]> > --- > Cc: Peter Zijlstra <[email protected]> > Cc: Ingo Molnar <[email protected]> > Cc: Will Deacon <[email protected]> > Cc: Boqun Feng <[email protected]> > Cc: Waiman Long <[email protected]> > --- > > [...] > > +RULE = always ((RT and SLEEP) imply (RT_FRIENDLY_SLEEP or > ALLOWLIST)) > + > +RT_FRIENDLY_SLEEP = (RT_VALID_SLEEP_REASON or KERNEL_THREAD) > + and ((not WAKE) until RT_FRIENDLY_WAKE) > + > +RT_VALID_SLEEP_REASON = PI_FUTEX > + or RT_FRIENDLY_NANOSLEEP > + > +RT_FRIENDLY_NANOSLEEP = CLOCK_NANOSLEEP > + and NANOSLEEP_TIMER_ABSTIME > + and NANOSLEEP_CLOCK_MONOTONIC > + > +RT_FRIENDLY_WAKE = WOKEN_BY_EQUAL_OR_HIGHER_PRIO > + or WOKEN_BY_HARDIRQ > + or WOKEN_BY_NMI > + or KTHREAD_SHOULD_STOP > + > +ALLOWLIST = BLOCK_ON_RT_MUTEX > + or TASK_IS_RCU > + or TASK_IS_MIGRATION
So, just thinking out loud, PI_FUTEX is a valid sleep reason, technically also BLOCK_ON_RT_MUTEX is something you are allowing. In my understanding, the contention tracepoints already in the kernel can track all contention by kernel code and are leaving aside the PI futexes, which use the untracked rt_mutex_wait_proxy_lock. In your case, you are tracking PI_FUTEX via the system call, which should cover the above scenario. Do you really need extra tracepoints to track this too? Or is there any other use of start_proxy_lock/wait_proxy_lock I'm missing here? I see the only case in which rt_mutex_start_proxy_lock is called with a task different than current is via FUTEX_CMP_REQUEUE_PI, wouldn't considering this one too make the new tracepoints superfluous (assuming this one is even needed to be tracked before FUTEX_WAIT_REQUEUE_PI). Thanks, Gabriele
