public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>,
	Aaron Lu <ziqianlu@bytedance.com>,
	Valentin Schneider <vschneid@redhat.com>,
	linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
	Andreas Ziegler <ziegler.andreas@siemens.com>,
	Felix Moessbauer <felix.moessbauer@siemens.com>,
	Florian Bezdeka <florian.bezdeka@siemens.com>
Subject: Re: [RT BUG] Stall caused by eventpoll, rwlocks and CFS bandwidth controller
Date: Tue, 15 Apr 2025 10:00:41 +0200	[thread overview]
Message-ID: <20250415080041.kePLxkOG@linutronix.de> (raw)
In-Reply-To: <f5520221-b5ec-4204-966c-881b3428d4c0@siemens.com>

On 2025-04-15 08:54:01 [+0200], Jan Kiszka wrote:
> On 15.04.25 08:23, Sebastian Andrzej Siewior wrote:
> > On 2025-04-15 07:35:50 [+0200], Jan Kiszka wrote:
> >>> On RT the read_lock() in the timer block, the write blocks, too. So
> >>> every blocker on the lock is scheduled out until the reader is gone. On
> >>> top of that, the reader gets RCU boosted with FIFO-1 by default to get
> >>> out.
> >>
> >> There is no boosting of the active readers on RT as there is no
> >> information recorded about who is currently holding a read lock. This is
> >> the whole point why rwlocks are hairy with RT, I thought.
> > 
> > Kind of, yes. PREEMPT_RT has by default RCU boosting enabled with
> > SCHED_FIFO 1. If you acquire a readlock you start a RCU section. If you
> > get stuck in a RCU section for too long then this boosting will take
> > effect by making the task, within the RCU section, the owner of the
> > boost-lock and the boosting task will try to acquire it. This is used to
> > get SCHED_OTHER tasks out of the RCU section.
> > But if a SCHED_FIFO task is on the CPU then this boosting will have to
> > no effect because the scheduler will not switch to a task with lower
> > priority.
> 
> Does that boosting happen to need ktimersd or ksoftirqd (which both are
> stalling in our case)? I'm still looking for the reason why it does not
> help in the observed stall scenarios.

Your problem is that you likely have many reader which need to get out
first. That spinlock replacement will help. I'm not sure about the CFS
patch referenced in the thread here.

That boosting requires a RCU reader that starts the mechanism (on rcu
unlock). But I don't think that it will help. You would also need to
raise the priority above to the writer level (manually) and that will
likely break other things. It is meant to unstuck SCHED_OTHER tasks and
not boost stuck reader as a side effect. Also I am not sure how that
works with multiple tasks.

> Jan

Sebastian

  reply	other threads:[~2025-04-15  8:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12 15:07 [RT BUG] Stall caused by eventpoll, rwlocks and CFS bandwidth controller Valentin Schneider
2025-04-09  6:41 ` Jan Kiszka
2025-04-09  9:29   ` K Prateek Nayak
2025-04-09 12:13     ` Aaron Lu
2025-04-09 13:44       ` Jan Kiszka
2025-04-14 14:50         ` K Prateek Nayak
2025-04-14 15:05           ` Sebastian Andrzej Siewior
2025-04-14 15:18             ` K Prateek Nayak
2025-04-15  5:35             ` Jan Kiszka
2025-04-15  6:23               ` Sebastian Andrzej Siewior
2025-04-15  6:54                 ` Jan Kiszka
2025-04-15  8:00                   ` Sebastian Andrzej Siewior [this message]
2025-04-15 10:23                     ` Jan Kiszka
2025-04-14 16:21           ` K Prateek Nayak
2025-04-09 13:21   ` Sebastian Andrzej Siewior
2025-04-09 13:41     ` Jan Kiszka
2025-04-09 13:52       ` Jan Kiszka
2025-04-09 13:57         ` Sebastian Andrzej Siewior

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=20250415080041.kePLxkOG@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=felix.moessbauer@siemens.com \
    --cc=florian.bezdeka@siemens.com \
    --cc=jan.kiszka@siemens.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=lgoncalv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vschneid@redhat.com \
    --cc=williams@redhat.com \
    --cc=ziegler.andreas@siemens.com \
    --cc=ziqianlu@bytedance.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