Linux Documentation
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox