Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp6678274rwb; Wed, 18 Jan 2023 08:06:09 -0800 (PST) X-Google-Smtp-Source: AMrXdXtcovaaehfbhCjSvtLH/CvXWuXE6Bdy/Ogw50Zfo18S4bow3r31GYkjBDAvxFutD6YiWzxw X-Received: by 2002:a17:902:b711:b0:185:50e4:f59c with SMTP id d17-20020a170902b71100b0018550e4f59cmr6056725pls.8.1674057969536; Wed, 18 Jan 2023 08:06:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674057969; cv=none; d=google.com; s=arc-20160816; b=XCdfsT4u5fd+UqCiowNvjuMDGGyAwDND0EP3uix+svnc4Jm3WLdR0KSdX9n51rMeW1 wzCe8YLz7dL7h/HF24KWcJLT8MGj8Qlky7DNYldlDNvGUNotX6mQAJ001YOqTz8yoUsE 4B0II6fl6kJI7VTqLhnibYmSRVVhI9XBlpyXqDiMfEF2052yyOrtNi8MbI70kjfRgglR gLOr2O5Hn/rDFs/IvIe3dFBSF7svBrVscQM76iwVoO90NiANcuhRm5awu0qioT95+s97 I7mqpm3ntWXpg7ql53y8v4tJeUtb51L5qgGMwEameYG8EuunSxEzIgpZIzBj3dVPiKGL TKMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:dkim-signature :dkim-signature:date; bh=BkBdwCC72vnFXKz7wAyBwaI38/pVFTFiaN/Bh+nVBec=; b=CwRi7JtnI6xv1JtpzkL7GAuoM+9Fzuz+sT2H0FQ9h+n+CEqo4qYrFx5abBg02Mz9sO PFOPiMRmq+3uuIGet+ogNE3zEci/6jHkn25PHKnR7V7eX5Ils7BHsnb8H8sgahb+Y2WC YFAqSA8Ftn9dzFFbLVudpbgu9CbCO0B8hkh+qUsJZRi0ItWKBuneeXn0X2KN0rtodahV H+eY8KsPty2TW7YjbfD5/ptyzNtcOUWiPYfmiz8BsiJqOmkIyKlw9HuEOtor7x3Oeewh SFwrToXhXWZu1vp26yDn6IqNz0ULZsdJqwPz0c2PYTL1RJ2LYsNiH7QrfFFSJx2Vn6M9 eNxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="0zN9/jm9"; dkim=neutral (no key) header.i=@linutronix.de; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 24-20020a631258000000b0048be2671cd0si30435721pgs.170.2023.01.18.08.06.03; Wed, 18 Jan 2023 08:06:09 -0800 (PST) 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="0zN9/jm9"; dkim=neutral (no key) header.i=@linutronix.de; 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 S229695AbjARP10 (ORCPT + 45 others); Wed, 18 Jan 2023 10:27:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231264AbjARP1K (ORCPT ); Wed, 18 Jan 2023 10:27:10 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A5C17298; Wed, 18 Jan 2023 07:26:01 -0800 (PST) Date: Wed, 18 Jan 2023 16:25:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1674055558; 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: in-reply-to:in-reply-to:references:references; bh=BkBdwCC72vnFXKz7wAyBwaI38/pVFTFiaN/Bh+nVBec=; b=0zN9/jm9ajNMr+mXoKrxvbTMD1MMQw2XozYf/rTD5Rd38p/D5vt982AvYA1EGF0zFjF3Zz U44RC2U/oKbyDxKdxdkYPnRP6xOlyI4S6Z9+lO+et/NO6ggLq4K8CIdDsv2MAB8Kf+rd0M IJnJfwjlkCl6U7rZwCe4GdhSMVTSqv2gtqYe2HAgUXp770vUvpoqyRdBtyYgFeaiowgbbc Kbo0IyIrR4OEPFGwvS5eCUK3mmISlbHdx/einy6lkmXTCVDgLZQYpN0PXhml9lnpIcjHLN FzWflrNs3w1GeZGYrFweVTD0+7JBuw4dvyUWnya2mdFPy4+E+YQqa3ZeE7+ORw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1674055558; 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: in-reply-to:in-reply-to:references:references; bh=BkBdwCC72vnFXKz7wAyBwaI38/pVFTFiaN/Bh+nVBec=; b=xYvHBkcXAL87G9vS7nzryaX9fr+1OJLj2dwhyt1g2IyitBFq+Fh0Q+ACn2B2bADJCgsf5r pyFqbuoQ6I0iA9Cg== From: Sebastian Andrzej Siewior To: Mel Gorman Cc: Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Davidlohr Bueso , Linux-RT , LKML Subject: Re: [PATCH v2] locking/rwbase: Prevent indefinite writer starvation Message-ID: References: <20230117083817.togfwc5cy4g67e5r@techsingularity.net> <20230117165021.t5m7c2d6frbbfzig@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230117165021.t5m7c2d6frbbfzig@techsingularity.net> 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 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: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-01-17 16:50:21 [+0000], Mel Gorman wrote: > diff --git a/kernel/locking/rwbase_rt.c b/kernel/locking/rwbase_rt.c > index c201aadb9301..99d81e8d1f25 100644 > --- a/kernel/locking/rwbase_rt.c > +++ b/kernel/locking/rwbase_rt.c > @@ -65,6 +69,64 @@ static __always_inline int rwbase_read_trylock(struct rwbase_rt *rwb) > return 0; > } > > +/* > + * Allow reader bias with a pending writer for a minimum of 4ms or 1 tick. > + * This matches RWSEM_WAIT_TIMEOUT for the generic RWSEM implementation. > + * The granularity is not exact as the lowest bit in rwbase_rt->waiter_timeout > + * is used to detect recent DL / RT tasks taking a read lock. > + */ > +#define RWBASE_RT_WAIT_TIMEOUT DIV_ROUND_UP(HZ, 250) > + > +static void __sched update_dlrt_reader(struct rwbase_rt *rwb) > +{ > + /* No update required if DL / RT tasks already identified. */ > + if (rwb->waiter_timeout & 1) > + return; > + > + /* > + * Record a DL / RT task acquiring the lock for read. This may result > + * in indefinite writer starvation but DL / RT tasks should avoid such > + * behaviour. > + */ > + if (rt_task(current)) { > + struct rt_mutex_base *rtm = &rwb->rtmutex; > + unsigned long flags; > + > + raw_spin_lock_irqsave(&rtm->wait_lock, flags); > + rwb->waiter_timeout |= 1; Let me see of I parsed the whole logic right: _After_ the RT reader acquired the lock, the lowest bit is set. This may be immediately if the timeout did not occur yet. With this flag set, all following reader incl. SCHED_OTHER will acquire the lock. If so, then I don't know why this is a good idea. If _only_ the RT reader is allowed to acquire the lock while the writer is waiting then it make sense to prefer the RT tasks. (So the check is on current and not on the lowest bit). All other (SCHED_OTHER) reader would have to block on the rtmutex after the timeout. This makes sense to avoid the starvation. If we drop that "we prefer the RT reader" then it would block on the RTmutex. It will _still_ be preferred over the writer because it will be enqueued before the writer in the queue due to its RT priority. The only downside is that it has to wait until all readers are left. So by allowing the RT reader to always acquire the lock as long as the WRITER_BIAS isn't set, we would allow to enter early while the other reader are still in and after the timeout you would only have RT reader going in and out. All SCHED_OTHER reader block on the RTmutex. I think I like this. > + raw_spin_unlock_irqrestore(&rtm->wait_lock, flags); > + } > +} > + Sebastian