From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta-65-225.siemens.flowmailer.net (mta-65-225.siemens.flowmailer.net [185.136.65.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DD853DBD76 for ; Fri, 4 Sep 2026 08:52:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.136.65.225 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788511947; cv=none; b=aICrYpgfei2q16ywXVHLERxXAp9spO5Zi8ChREam8piVn8uqLWtZB9gdbhBdJBmhCfvTc6so5XlDFFmPqBM9iTnvu/pJ0Ru8QLCjPVWDw2csmDAyLtZBdqj0pKrU4G8ah0mSCE7q0x01mxceyiRvEtlln8qCtoamcgqFXNhzwwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788511947; c=relaxed/simple; bh=zwOgrFX7s8Bq/2iYUD9jj5MO5VT9r915r6LJ7serWUc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=CQa+S7UK9iID9ItAj2VOUGIsYYWgj4S3+Z5IAaAmNmvmuO908HqtpgLe1u0ozX0XCmNurhMrGt1WMd9h5eZiHYcrleOzPEz/+InSP9c/7HNuxesH2ZUnFfpCVJvecfTjyZI6x8o/23nlXKvO2h81j5GROi58xeNqNdSo/37fhkA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b=DqbGfofz; arc=none smtp.client-ip=185.136.65.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=siemens.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rts-flowmailer.siemens.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=siemens.com header.i=florian.bezdeka@siemens.com header.b="DqbGfofz" Received: by mta-65-225.siemens.flowmailer.net with ESMTPSA id 20260904085212ad388744b70002078c for ; Fri, 04 Sep 2026 10:52:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm2; d=siemens.com; i=florian.bezdeka@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc:References:In-Reply-To; bh=zwOgrFX7s8Bq/2iYUD9jj5MO5VT9r915r6LJ7serWUc=; b=DqbGfofztkaz5loDe1pvYHs+fSnVuiHF577LWy+0S0V/gzc+AFS6eJOU+RRdkG4gaJSFIg AwORgqQUBoV15D9z0UIyPQZBsNYXV1RyrBoFmwFwnyrekd4hLvJSSImKO8MANuwMUiYk+Oco Re2zvZVIrpfvXEIhXkOnk3DsdHN3LMrU1nHEaJVvlUNgMBVh3xzarVWnDS844/yG1l+Tok/v 8+SSzFJlhmnO9YMTkTzHhVSdPeDFf5ATodCNxKFoCd9MpQ6c+OvtlnRzMgcUpEhnFTqBUZsS Z5USkNAdM2STGSeyHzcjZ0dErdxGQWBaoOwt9mEUTBgnW+cALk+UB15g==; Message-ID: <63d5cd58e9b85acccdaaac9aed4a8c550cc7b868.camel@siemens.com> Subject: Re: [QUESTION] Are these issues PREEMPT_RT-specific? From: Florian Bezdeka To: Ran Hongyun , namcao@linutronix.de Cc: axboe@kernel.dk, bigeasy@linutronix.de, brauner@kernel.org, clrkwllms@kernel.org, frederic@kernel.org, jack@suse.cz, jdamato@fastly.com, john.ogness@linutronix.de, kprateek.nayak@amd.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, linux-rt-users@vger.kernel.org, mkarsten@uwaterloo.ca, rostedt@goodmis.org, stable@vger.kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, vschneid@redhat.com, xry111@xry111.site, chengzhihao1@huawei.com, yangerkun@huawei.com, yi.zhang@huawei.com, wozizhi@huawei.com Date: Fri, 04 Sep 2026 10:52:11 +0200 In-Reply-To: <20260904081149.3000727-1-ranhongyun1@huawei.com> References: <20260904081149.3000727-1-ranhongyun1@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-68982:519-21489:flowmailer On Fri, 2026-09-04 at 16:11 +0800, Ran Hongyun wrote: > The commit eb0d280c2751 ("eventpoll: Replace rwlock with spinlock") aims = to fix: >=20 > 1.Priority inversion =E2=80=93 On PREEMPT_RT, rwlock_t readers lack prior= ity > inheritance (PI), so a low-priority reader holding the lock can be > preempted by a medium-priority task, blocking a high-priority writer > indefinitely. >=20 > 2.Stall =E2=80=93 A reader (p_read) holding the lock can be throttled by = CFS > bandwidth control and scheduled out. A writer (p_write) blocks waiting > for the lock, and a timer thread (ktimers/n) needed to replenish p_read's > runtime is blocked due to writer-fairness (286deb7ec03d). This forms a > circular dependency and stalls the system. >=20 > Are these issues PREEMPT_RT-specific?=20 No, but it's way more critical on PREEMPT_RT. !RT systems will see a "performance" or "throughput" drop but not a critical system stall. >=20 > Any clarification would be appreciated. 2. was addressed in 6.18 by deferring the throttling to the place where a task exits to user mode. See [1] for further reference. [1] was not backported to older (stable) kernels but the commit you referenced at the top was, so the 2. problem is gone there was well. HTH, Florian [1] https://lore.kernel.org/all/20250829081120.806-1-ziqianlu@bytedance.com= /