Message ID | 20230321161140.HMcQEhHb@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:1828:b0:ab:1fc6:e12a with SMTP id l40csp2445179dyk; Tue, 21 Mar 2023 09:24:53 -0700 (PDT) X-Google-Smtp-Source: AK7set9qUwHWxE1ebzxxfqt0xTerSJYB98DSyrsgT9uqFk/9kiezG1WVYbO1cOnGw3PWVUWmh35v X-Received: by 2002:a05:6a20:7aa0:b0:d9:dfc:4cb6 with SMTP id u32-20020a056a207aa000b000d90dfc4cb6mr3143489pzh.35.1679415892736; Tue, 21 Mar 2023 09:24:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679415892; cv=none; d=google.com; s=arc-20160816; b=krb2q8zqgZbfIC/W5NaS9sXqnIMp53MJ+1x2b4JbO0tV4t0FZBvKvVB55/7Olxv8MI mwN/KJjd3BJg5wI2orJ5HPWrNcVGGilOm9ZUgDyjZypPJdzAISkUZj4P/0gDcPI7eVyN p/lbBS/MAK2TnEx09zfd5wsg3qgjWRhcUkx4stLXknfFjqt+E/f9EazKIteQ2bgWZbHY YVuEU2eg1iv0xLYroZulRMavBiC6df/Svdd6jsewOtP2fLtuWLqeP6GpK67HfwT97zxl l69Qbr6K77gxs5efbSlAsUsqX0z7pNRAsIUjbl8dJsAyKYEftbCLLsuXeKK42tjBtZYF g4+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:dkim-signature:dkim-signature:date; bh=nG0bOzqdgsuZ4sSUc4UXldoJdmKCghe+OL+gnubJm/U=; b=jo4a6khxGsRcEIrNi8IclqzeTUTfboBTa6BKXU8CtC2h15i7iPumz7yRF0av7D2Sb+ vzaB4g1AfL9VZxU5mCnkDwzVUl3jKLjqTys6VZGYdU2lqbTUKhxZ0xg7mx7V1qiKFMpp uQjC5Ayg12OfLaWaRfG2UOjDVL2B2tI6ypwTmI6vLNRqYRBwa+vlG4DprmuAPmyThQ4z u4YdirVNdT91ksxGvx4XtlG+QNvniQm+16A9ui6hn9qJkrtIV/dgzte7LmJP/KejJnk2 wy2qjnFptUI3BMSw8olvI07JHUkcJsuWQzYiw9g8oBKcGE0Ftmm1/Iv/4a3beywzUrZW Ty6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jJpuOhRc; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=HtVblRZN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bk13-20020a056a02028d00b0050f8790a843si5341612pgb.189.2023.03.21.09.24.39; Tue, 21 Mar 2023 09:24:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jJpuOhRc; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=HtVblRZN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230054AbjCUQLs (ORCPT <rfc822;ezelljr.billy@gmail.com> + 99 others); Tue, 21 Mar 2023 12:11:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229583AbjCUQLq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Mar 2023 12:11:46 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0B1D4D297; Tue, 21 Mar 2023 09:11:44 -0700 (PDT) Date: Tue, 21 Mar 2023 17:11:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1679415102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=nG0bOzqdgsuZ4sSUc4UXldoJdmKCghe+OL+gnubJm/U=; b=jJpuOhRcELM19ikq6o6peDpFolcfScaGLaNM8vHLDcS+6bhoPiMD9/Nbn0JpO/CDxxI2FU 9wBfiBLoe74DbcBzGjsjoFkfQr1BkdAPS89Eej/gCIT23RwHvL9h+7N/I97Y0E4bOoKANQ o5SIznCLfxG2O5r08hvJLbtTL8OvhY/+4sTz+foiwCuyRV0QATb+2TNKYiRWMde6YIc1el LQTMRYo03ZymIHkFNgw032Oa2688gQrhloXvi7Ek1t7xgps+piG2tlwLSmu2qfSz97c7MK POAo02BCl9ZZyYCFE36z4DlW6iOanWfX3fal6XtLxMOheYb77migsFkeey0Y8Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1679415102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=nG0bOzqdgsuZ4sSUc4UXldoJdmKCghe+OL+gnubJm/U=; b=HtVblRZN8VEhdTg0yUDC5F1Pr7yJQqO2u1qqfa0HDbzNzKDXpPob2YLcxvbYynx/fl03aE QwNqIet1mEWH2rDA== From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> To: Thomas Gleixner <tglx@linutronix.de> Cc: Mel Gorman <mgorman@techsingularity.net>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Davidlohr Bueso <dave@stgolabs.net>, Linux-RT <linux-rt-users@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: [PATCH v6] locking/rwbase: Mitigate indefinite writer starvation. Message-ID: <20230321161140.HMcQEhHb@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760995199006348247?= X-GMAIL-MSGID: =?utf-8?q?1760995199006348247?= |
Series |
[v6] locking/rwbase: Mitigate indefinite writer starvation.
|
|
Commit Message
Sebastian Andrzej Siewior
March 21, 2023, 4:11 p.m. UTC
The rw_semaphore and rwlock_t locks are unfair to writers. Readers can
indefinitely acquire the lock unless the writer fully acquired the lock.
This can never happen if there is always a reader in the critical
section owning the lock.
Mel Gorman reported that since LTP-20220121 the dio_truncate test case
went from having 1 reader to having 16 reader and the number of readers
is sufficient to prevent the down_write ever succeeding while readers
exist. Eventually the test is killed after 30 minutes as a failure.
Mel proposed a timeout to limit how long a writer can be blocked until
the reader is forced into the slowpath.
Thomas argued that there is no added value by providing this timeout.
From PREEMPT_RT point of view, there are no critical rw_semaphore or
rwlock_t locks left where the reader must be prefer.
Mitigate indefinite writer starvation by forcing the READER into the
slowpath once the WRITER attempts to acquire the lock.
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/877cwbq4cq.ffs@tglx
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
- v5..v6: https://lore.kernel.org/all/Y+0W0wgyaJqYHKoj@linutronix.de/
- dropped the timeout and forcing reader into the slowpath once a
writer is waiting.
- v4..v5 https://lore.kernel.org/20230120140847.4pjqf3oinemokcyp@techsingularity.net
- Reworded last paragraph of the commit message as Mel's suggestion
- RT/DL tasks are no longer excluded from the waiter timeout. There
is no reason why this should be done since no RT user relies on
rwsem (and would need this kind of behaviour). The critical user
from RT perspective replaced rwsem with RCU.
Avoiding special treatment avoids this kind of bug with RT
readers.
- Update comments accordingly.
kernel/locking/rwbase_rt.c | 9 ---------
1 file changed, 9 deletions(-)
Comments
On Tue, Mar 21, 2023 at 05:11:40PM +0100, Sebastian Andrzej Siewior wrote: > The rw_semaphore and rwlock_t locks are unfair to writers. Readers can > indefinitely acquire the lock unless the writer fully acquired the lock. > This can never happen if there is always a reader in the critical > section owning the lock. > > Mel Gorman reported that since LTP-20220121 the dio_truncate test case > went from having 1 reader to having 16 reader and the number of readers > is sufficient to prevent the down_write ever succeeding while readers > exist. Eventually the test is killed after 30 minutes as a failure. > > Mel proposed a timeout to limit how long a writer can be blocked until > the reader is forced into the slowpath. > Thomas argued that there is no added value by providing this timeout. > From PREEMPT_RT point of view, there are no critical rw_semaphore or > rwlock_t locks left where the reader must be prefer. > s/prefer/preferred/ > Mitigate indefinite writer starvation by forcing the READER into the > slowpath once the WRITER attempts to acquire the lock. > > Reported-by: Mel Gorman <mgorman@techsingularity.net> > Link: https://lore.kernel.org/877cwbq4cq.ffs@tglx > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Mel Gorman <mgorman@techsingularity.net> Thanks Sebastian and Thomas!
diff --git a/kernel/locking/rwbase_rt.c b/kernel/locking/rwbase_rt.c index c201aadb93017..25ec0239477c2 100644 --- a/kernel/locking/rwbase_rt.c +++ b/kernel/locking/rwbase_rt.c @@ -72,15 +72,6 @@ static int __sched __rwbase_read_lock(struct rwbase_rt *rwb, int ret; raw_spin_lock_irq(&rtm->wait_lock); - /* - * Allow readers, as long as the writer has not completely - * acquired the semaphore for write. - */ - if (atomic_read(&rwb->readers) != WRITER_BIAS) { - atomic_inc(&rwb->readers); - raw_spin_unlock_irq(&rtm->wait_lock); - return 0; - } /* * Call into the slow lock path with the rtmutex->wait_lock