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: Valentin Schneider <vschneid@redhat.com>,
	linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	kprateek.nayak@amd.com, 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: Wed, 9 Apr 2025 15:57:20 +0200	[thread overview]
Message-ID: <20250409135720.YuroItHp@linutronix.de> (raw)
In-Reply-To: <905b3cca-e9ab-4844-bbe2-aa9a8c78e047@siemens.com>

On 2025-04-09 15:52:19 [+0200], Jan Kiszka wrote:
> On second glance, Frederic's patch would probably also avoid the issue
> we are seeing as it should bring PI to the CFS-throttled read-lock
> holder (which is now a write-lock holder).
> 
> But given how old that proposal is, I assume the performance impact was
> even for the RT kernel too much, wasn't it?

I don't remember any numbers and how bad things would get just the fear
of it. But I guess this is workload related in terms how much does the
RW lock improve the situation. RT then will multiple the CPU and reader
resources to the point where it does not scale and present you the
lockups.

> Jan

Sebastian

      reply	other threads:[~2025-04-09 13:57 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
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 [this message]

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=20250409135720.YuroItHp@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 \
    /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