From: Gabriele Monaco <gmonaco@redhat.com>
To: Chao Liu <chao.liu@processmission.com>, Nam Cao <namcao@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Jonathan Corbet <corbet@lwn.net>,
zhouzhouyi@gmail.com, lianux.mm@gmail.com,
lianux.wang@processmission.com,
Shuah Khan <skhan@linuxfoundation.org>,
linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2] Documentation/rv: Explain epoll and aborted sleeps
Date: Tue, 04 Aug 2026 12:45:16 +0200 [thread overview]
Message-ID: <c9fbfea2eeb6603f275365e61bef0bbfb355d963.camel@redhat.com> (raw)
In-Reply-To: <20260729081102.73138-1-chao.liu@processmission.com>
On Wed, 2026-07-29 at 16:11 +0800, Chao Liu wrote:
> epoll_wait() is a valid sleeping reason for real-time tasks because it
> uses PI-aware locking, but the rtapp sleep monitor documentation only
> discusses clock_nanosleep() and futexes. Document it.
>
> ABORT_SLEEP represents a task restoring TASK_RUNNING before entering
> the scheduler. Since the task does not actually block, it becomes
> runnable again without a wakeup sequence unsafe for real-time. Document
> this behavior.
>
Looks good, thanks! Please next time you send a patch, even if it's an RFC, put
the extra comments after the --- . This way I can pull it directly without
changing the commit message because git am ignores everything after the --- .
Also, no big deal, but for simple patches like this one, and even after getting
comments, there's no need to mark as RFC.
Reviewed-by: Gabriele Monaco <gmonaco@redhat.com>
I'd appreciate an ack from Nam, then I might be able to squeeze this before the
merge window together with the last fixes.
Thanks,
Gabriele
> This RFC is based on Nam Cao's pending "rv: rtapp monitor update" v2
> series:
>
> https://lore.kernel.org/r/cover.1781852967.git.namcao@linutronix.de
>
> Signed-off-by: Chao Liu <chao.liu@processmission.com>
> ---
> Changes in v2:
> - Explain why epoll_wait() is RT-safe in terms of PI-aware locking.
> - Explain that ABORT_SLEEP does not require an RT-unsafe wakeup sequence.
> - Update the commit message accordingly.
>
> Link to v1:
> https://lore.kernel.org/linux-trace-kernel/20260722045706.85633-1-chao.liu@processmission.com/
>
> Documentation/trace/rv/monitor_rtapp.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/trace/rv/monitor_rtapp.rst
> b/Documentation/trace/rv/monitor_rtapp.rst
> index 238b59395ff5..b95994ade14a 100644
> --- a/Documentation/trace/rv/monitor_rtapp.rst
> +++ b/Documentation/trace/rv/monitor_rtapp.rst
> @@ -67,6 +67,8 @@ thread to sleep for one of the following reasons:
> variables as safe for real-time. As an alternative, the librtpi library
> exists to provide a conditional variable implementation that is correct
> for
> real-time applications in Linux.
> + - Real-time thread waiting for events using `epoll_wait`, which is a
> + real-time-safe syscall for sleeping as it uses PI-aware locking.
>
> Beside the reason for sleeping, the eventual waker should also be
> real-time-safe. Namely, one of:
> @@ -114,6 +116,10 @@ The monitor's specification is::
> ALLOWLIST = BLOCK_ON_RT_MUTEX
> or FUTEX_LOCK_PI
>
> +`ABORT_SLEEP` represents a task restoring its state to `TASK_RUNNING` before
> +entering the scheduler. In this case, the task does not actually block, so
> the
> +task is back to runnable without any wakeup sequence unsafe for real-time.
> +
> Beside the scenarios described above, this specification also defines an
> allow list
> to handle some special cases:
>
>
> base-commit: 248951ddc14de84de3910f9b13f51491a8cd91df
> prerequisite-patch-id: d8b6c952a954662852e6b0684e0a3386eaab7f41
> prerequisite-patch-id: 940f7637aeabe4ba15a09c048c6f48138406f332
> prerequisite-patch-id: b99812692691f76d825778e01a2e771e058febd6
> prerequisite-patch-id: 512c300dce2cb74ac9cc007f9234aa507ef5c008
next prev parent reply other threads:[~2026-08-04 10:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 8:11 [RFC PATCH v2] Documentation/rv: Explain epoll and aborted sleeps Chao Liu
2026-08-04 10:45 ` Gabriele Monaco [this message]
2026-08-04 14:02 ` Nam Cao
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=c9fbfea2eeb6603f275365e61bef0bbfb355d963.camel@redhat.com \
--to=gmonaco@redhat.com \
--cc=chao.liu@processmission.com \
--cc=corbet@lwn.net \
--cc=lianux.mm@gmail.com \
--cc=lianux.wang@processmission.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=namcao@linutronix.de \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=zhouzhouyi@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.