[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250409132149.rFrzBCrP@linutronix.de>
Date: Wed, 9 Apr 2025 15:21:49 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Jan Kiszka <jan.kiszka@...mens.com>
Cc: Valentin Schneider <vschneid@...hat.com>,
linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
kprateek.nayak@....com, Thomas Gleixner <tglx@...utronix.de>,
Juri Lelli <juri.lelli@...hat.com>,
Clark Williams <williams@...hat.com>,
"Luis Claudio R. Goncalves" <lgoncalv@...hat.com>,
Andreas Ziegler <ziegler.andreas@...mens.com>,
Felix Moessbauer <felix.moessbauer@...mens.com>,
Florian Bezdeka <florian.bezdeka@...mens.com>
Subject: Re: [RT BUG] Stall caused by eventpoll, rwlocks and CFS bandwidth
controller
On 2025-04-09 08:41:44 [+0200], Jan Kiszka wrote:
> We are hunting for quite some time sporadic lock-ups or RT systems,
> first only in the field (sigh), now finally also in the lab. Those have
> a fairly high overlap with what was described here. Our baselines so
> far: 6.1-rt, Debian and vanilla. We are currently preparing experiments
> with latest mainline.
>
> While this thread remained silent afterwards, we have found [1][2][3] as
> apparently related. But this means we are still with this RT bug, even
> in latest 6.15-rc1?
Not sure the commits are related. The problem here is that RW locks are
not really real time friendly. Frederick had a simple fix to it
https://lore.kernel.org/all/20210825132754.GA895675@lothringen/
but yeah. The alternative, which I didn't look into, would be to replace
the reader side with RCU so we would just have the writer lock. That
mean we need to RW lock because of performance…
> Jan
>
> [1] https://lore.kernel.org/lkml/20231030145104.4107573-1-vschneid@redhat.com/
> [2] https://lore.kernel.org/lkml/20240202080920.3337862-1-vschneid@redhat.com/
> [3] https://lore.kernel.org/lkml/20250220093257.9380-1-kprateek.nayak@amd.com/
>
Sebastian
Powered by blists - more mailing lists