From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Jan Kiszka <jan.kiszka@siemens.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: Mon, 14 Apr 2025 17:05:13 +0200 [thread overview]
Message-ID: <20250414150513.klU46xkw@linutronix.de> (raw)
In-Reply-To: <f2e2c74c-b15d-4185-a6ea-4a19eee02417@amd.com>
On 2025-04-14 20:20:04 [+0530], K Prateek Nayak wrote:
> Note: I could not reproduce the splat with !PREEMPT_RT kernel
> (CONFIG_PREEMPT=y) or with small loops counts that don't exhaust the
> cfs bandwidth.
Not sure what this has to do with anything.
On !RT the read_lock() in the timer can be acquired even with a pending
writer. The writer keeps spinning until the main thread is gone. There
should be no RCU boosting but the RCU still is there, too.
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.
Sebastian
next prev parent reply other threads:[~2025-04-14 15:05 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 [this message]
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
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=20250414150513.klU46xkw@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