linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nam Cao <namcao@linutronix.de>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	john.ogness@linutronix.de
Subject: Re: [PATCH v2 21/22] rv: Add documentation for rtapp monitor
Date: Wed, 16 Apr 2025 06:37:27 +0200	[thread overview]
Message-ID: <20250416043727.4c1KgDrO@linutronix.de> (raw)
In-Reply-To: <67d9e857fd4fbfe590c9472f1c74b6f22560d952.camel@redhat.com>

On Tue, Apr 15, 2025 at 03:12:23PM +0200, Gabriele Monaco wrote:
> On Fri, 2025-04-11 at 09:37 +0200, Nam Cao wrote:
> > +  - `RT_SLEEP_WHITELIST`: to handle known false positives with
> > kernel tasks.
> 
> Is this what you call ALLOWLIST?

Yes. A colleague already poked me off-list about this error :(

> Just out of curiosity, normal kernel threads are not forced to follow a
> VALID_SLEEP_REASON but need RT_FRIENDLY_WAKE, how are tasks like RCU
> and migration not following this?

Because that's how RCU and migration works, they are intended to be woken
by anything.

It is also possible that people deliberately design their userspace
real-time threads to be woken by non-real-time threads. For example,
pipewire has a non-real-time thread waking a real-time thread to do some
non-critical work. That's still okayish from real-time perspective (but it
is better if the non-real-time thread just does the work itself).

This monitor's warning is not exactly a "here's a bug, fix it". But more
like "something seems really wrong here, please investigate". People can
decide whether this particular suspicious instance is acceptable for their
case.

The initial implementation of the monitor didn't have this allowlist. And
we had a bunch of warnings on the rcu_preempt and migration/ threads. We
decided that due to how rcu and migration works, these warnings are okay.

> The monitors are not designed for deadline tasks, any plan to extend to
> those too?

I haven't thought much about deadline tasks. But it could be extended by
changing "RT" into "RT or DL", if needed.

> Other than this, nice explanation and monitors, thanks.
> 
> Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>

Thanks so much for the review!
Nam

  reply	other threads:[~2025-04-16  4:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11  7:37 [PATCH v2 00/22] RV: Linear temporal logic monitors for RT application Nam Cao
2025-04-11  7:37 ` [PATCH v2 01/22] rv: Fix out-of-bound memory access in rv_is_container_monitor() Nam Cao
2025-04-11  7:37 ` [PATCH v2 02/22] rv: Add #undef TRACE_INCLUDE_FILE Nam Cao
2025-04-11  7:37 ` [PATCH v2 03/22] rv: Let the reactors take care of buffers Nam Cao
2025-04-11  8:39   ` Gabriele Monaco
2025-04-15  9:32   ` Petr Mladek
2025-04-15  9:53     ` Nam Cao
2025-04-11  7:37 ` [PATCH v2 04/22] verification/dot2k: Make it possible to invoke dot2k without installation Nam Cao
2025-04-11  9:23   ` Gabriele Monaco
2025-04-11 14:04     ` Nam Cao
2025-04-11 14:56       ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 05/22] verification/dot2k: Make a separate dot2k_templates/Kconfig_container Nam Cao
2025-04-11  8:54   ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 06/22] verification/dot2k: Remove __buff_to_string() Nam Cao
2025-04-11  8:53   ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 07/22] verification/dot2k: Replace is_container() hack with subparsers Nam Cao
2025-04-11  8:56   ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 08/22] rv: rename CONFIG_DA_MON_EVENTS to CONFIG_RV_MON_EVENTS Nam Cao
2025-04-11 10:37   ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 09/22] verification/dot2k: Prepare the frontend for LTL inclusion Nam Cao
2025-04-11  7:37 ` [PATCH v2 10/22] Documentation/rv: Prepare monitor synthesis document " Nam Cao
2025-04-11  9:28   ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 11/22] verification/rvgen: Prepare the templates " Nam Cao
2025-04-11  7:37 ` [PATCH v2 12/22] verification/rvgen: Restructure the classes to prepare " Nam Cao
2025-04-11  7:37 ` [PATCH v2 13/22] rv: Add support for LTL monitors Nam Cao
2025-04-11 11:17   ` Gabriele Monaco
2025-04-11 14:15     ` Nam Cao
2025-04-15 13:22   ` Gabriele Monaco
2025-04-16  3:55     ` Nam Cao
2025-04-11  7:37 ` [PATCH v2 14/22] rv: Add rtapp container monitor Nam Cao
2025-04-11  7:37 ` [PATCH v2 15/22] x86/tracing: Remove redundant trace_pagefault_key Nam Cao
2025-04-11  7:37 ` [PATCH v2 16/22] x86/tracing: Move page fault trace points to generic Nam Cao
2025-04-11  7:37 ` [PATCH v2 17/22] arm64: mm: Add page fault trace points Nam Cao
2025-04-11  7:37 ` [PATCH v2 18/22] riscv: " Nam Cao
2025-04-11  7:37 ` [PATCH v2 19/22] rv: Add rtapp_pagefault monitor Nam Cao
2025-04-15 12:31   ` Gabriele Monaco
2025-04-15 12:38     ` Nam Cao
2025-04-15 12:47       ` Gabriele Monaco
2025-04-11  7:37 ` [PATCH v2 20/22] rv: Add rtapp_sleep monitor Nam Cao
2025-04-11  7:37 ` [PATCH v2 21/22] rv: Add documentation for rtapp monitor Nam Cao
2025-04-15 13:12   ` Gabriele Monaco
2025-04-16  4:37     ` Nam Cao [this message]
2025-04-11  7:37 ` [PATCH v2 22/22] rv: Allow to configure the number of per-task monitor Nam Cao
2025-04-11 12:31   ` Gabriele Monaco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250416043727.4c1KgDrO@linutronix.de \
    --to=namcao@linutronix.de \
    --cc=gmonaco@redhat.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).