From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B8D8C61D85 for ; Tue, 21 Nov 2023 00:46:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9034B6B037C; Mon, 20 Nov 2023 19:46:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B4056B037E; Mon, 20 Nov 2023 19:46:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77A866B0381; Mon, 20 Nov 2023 19:46:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 682726B037C for ; Mon, 20 Nov 2023 19:46:05 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 44603C0582 for ; Tue, 21 Nov 2023 00:46:05 +0000 (UTC) X-FDA: 81480119490.14.C78E1D4 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf05.hostedemail.com (Postfix) with ESMTP id E3843100002 for ; Tue, 21 Nov 2023 00:46:02 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GEhEQKFi; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700527563; a=rsa-sha256; cv=none; b=RyGwSKEa6b1DNrh6q9YvWoJmghhk4Tah+uT3umFDbXNYQ8uUAs0gI5JDld0MRkeJrGpykh 985oKF063ABnPYmPs8EuazNa8oU5NMhWNKpsDf12RbFUdAPVFi/vDxON10nriHNDSvy4BB 2jMlZlzA2sZo4NA2+NWicXQw0qMSUoI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GEhEQKFi; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf05.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700527563; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eshtWvPOFX3Tlf22iYY/29K6fpahKTJFhj6OA0/TwtQ=; b=ve/U1P2HrnpZ345GuyACX2pVJPqeug7rv+ztEKPEf9BxQ9OCPMosNLcDeTmqbqJVPufpLS YtA6d4f/Eo95NMejYxABVEcn97GIJ21aOJEfWW5v1clpIoqMsGXqgMZTZCh2DGwBuSmaz7 vrdH3qIa+etPmfUOBEffATiQPVfakhI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id E5EB0CE17FD; Tue, 21 Nov 2023 00:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A5D8C433C7; Tue, 21 Nov 2023 00:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700527558; bh=7ITtsMr3bGAuekf6mH52bfGLbeQOxBb4WvruWUP+jT8=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=GEhEQKFi84qpoygDqVA5aG1BtFAA18v55zAnBg31Nn9mQklTdwnwuqoZyUPpkR7UU tfIl3zVZKT5Occ1ud0QwQ93dGJC6znGLlhL8GaiVRbSJj01MlUuk5wjbNESkENOYGH SYnuFHCerdtboi27/+nn1YUtl2RUt/GH9h9ddkpVKmlGCzZnKkJD3jehwm/F0HQOBh o7RGT0QxSdQfiArw8DtRu9vHZY6Lbtk2wx1Z/kbCFPyJG1zCSWegHlHNCCUM82SHS7 mg9oGTK7L8dlDzr24vwA0AdrBrP9s4gZOaZQo47dje9l2NvS/IkSAJNVjoWAJK2esp tM+kleucCPwcg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id BF132CE1390; Mon, 20 Nov 2023 16:45:57 -0800 (PST) Date: Mon, 20 Nov 2023 16:45:57 -0800 From: "Paul E. McKenney" To: Ankur Arora Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Julia Lawall , Nicolas Palix Subject: Re: [RFC PATCH 57/86] coccinelle: script to remove cond_resched() Message-ID: <7d85fbde-fc8d-44b4-802e-376a475891e6@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107230822.371443-1-ankur.a.arora@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231107230822.371443-1-ankur.a.arora@oracle.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E3843100002 X-Stat-Signature: w6o4hi9j9zciekasgjo7jjcgjcupansp X-HE-Tag: 1700527562-265943 X-HE-Meta: U2FsdGVkX19g7TPs4ZYxUQ8mlAvrnFv9+4/pRe+Ax45zs4rB6tGyt5r23vx2TNW139qefOtv0UfjXTVtKSRJeGhk6n6yd5hSOYNKClhA2xdMFfSGvB0wH2G/UWfsHkN9Ss3bbeTRcxIA38z7J8VIwM3+TcmIBImy9deqoMtGfMJgoULvGs2LAbCWPczw1OuZB/pnra3JbR0bUhoIat46jW65N27ikROaQchRogygCjApanNo9VtmHtCk89vEDLbpXTL6Jzc4B6zut8IbiP609kkvwUBTteLKyxQh0kRxMRbb2Jj0APNQ+Z+4IqEqzax53fRsmErKu9gMgK+dzjyo9EO3JdQVDC7e7tnJ27nbFNgfFrn+47oxtnQgdgwBjrUoPrrV2v0kHBoCFzZGBotazmYqXJAZgd7gGxA+WBvVdT121mvnGDoJonnWhdM25vFRDcpBAx2uP73BSltlQIQ++jdj6GwHvoRRz+vW1V3yXK6VwrqGhsxJmlwBYJSkwylVfnF7+426E0hITUtJU36t2pK19WxHfn5OPbfTpftcjum6DWrMfkdK7xr2SsG75RKeGjtmgTIWcKql50HzrvNoCy4FiT5qQkNFCCzqrM1XTz7CojXc4wSy9xFkt+MHVw1nhTVP8avrhwvfUkR33gBMa7hOx9Be8PEXHCHyQ4iPXIvkJtDidPbS3OEkVyYoxZS1Tm0qBkVPoC1BoJ/Yz1oTphW6wMuIr9yXN4gXKl9usbkOnA2dvfbkwW6m93yVaUrFvEBajyH8w3NugWZ97mnnN9TpOh/14wXLo/0Tk4070Wh8C/rjm+zyq/UesBCat1z8F2nuk/Mkg33IheBjIoq3EnK3c7q3yKtoyz1/9e3QvcLf+6UVk0SYG4yQBC/LHKu20sUnWm2jnD12PMPJohS8aSPNd9ZmQlG3j6lJM9112vpjIrV3lfZ/drzxSwjAwnzlequRaD7yzQLjfLXZefw Bo96TSUf 2eVsLWBnL1Wkkcmm9qVwsi3b6vUJY2vEjXQ/xedZbJB+rroG2BqXYtzlH/LHqc2zK7eLUdJd8dV8fRd5rda73YIWf1G0OrwpyLAWAj+3KJF+v/od/L42hGFVQYDYXZ+7fS0KvUiS+FWzvzQyZdSccENFtgLP5vTKMVCIowRYKK6xYvf0VpWCyFQvcbe22M/XMTkO8pCMaOQTNs9Dd6BQO4JJ56vprRIczIgMrmCGvlSeM9taAVNPinvShY5GJsTQDuPsmfZL1tLuB1sS/CaGCfsjkcES3566101I9IDMBxpAYNdM8Vrevz8fV3+HIRg1cqPwFVM1JylyOxQIArfWs5wcI282rSSJjxHdqtJyAp3sqV0iC7JfboO9cPaPDNI6MQhoFdDwn3JXeYW+qDx6l+SnADemS6Vhh6R8x952M9P5eJmwosK5+mqGwuLk5S3E4qEJQhFqgsaTy0+k1RywP+1pbSa/OlUId1xVv+HQfYpqzIDYJ1zaYW3bQ//aszwjHIOM0NS9irAxeDRup84PJTGfyaC+5rq5qn3SlF7OYCbOgQTXNWblq/P1ZJiLZ0RJ7DWVOG01H2kTyc5/XmorpTlvHvhVYK2Zzq64ECsw5Gq1M2+c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Nov 07, 2023 at 03:07:53PM -0800, Ankur Arora wrote: > Rudimentary script to remove the straight-forward subset of > cond_resched() and allies: > > 1) if (need_resched()) > cond_resched() > > 2) expression*; > cond_resched(); /* or in the reverse order */ > > 3) if (expression) > statement > cond_resched(); /* or in the reverse order */ > > The last two patterns depend on the control flow level to ensure > that the complex cond_resched() patterns (ex. conditioned ones) > are left alone and we only pick up ones which are only minimally > related the neighbouring code. This series looks to get rid of stall warnings for long in-kernel preempt-enabled code paths, which is of course a very good thing. But removing all of the cond_resched() calls can actually increase scheduling latency compared to the current CONFIG_PREEMPT_NONE=y state, correct? If so, it would be good to take a measured approach. For example, it is clear that a loop that does a cond_resched() every (say) ten jiffies can remove that cond_resched() without penalty, at least in kernels built with either CONFIG_NO_HZ_FULL=n or CONFIG_PREEMPT=y. But this is not so clear for a loop that does a cond_resched() every (say) ten microseconds. Or am I missing something here? Thanx, Paul > Cc: Julia Lawall > Cc: Nicolas Palix > Signed-off-by: Ankur Arora > --- > scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 scripts/coccinelle/api/cond_resched.cocci > > diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci > new file mode 100644 > index 000000000000..bf43768a8f8c > --- /dev/null > +++ b/scripts/coccinelle/api/cond_resched.cocci > @@ -0,0 +1,53 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/// Remove naked cond_resched() statements > +/// > +//# Remove cond_resched() statements when: > +//# - executing at the same control flow level as the previous or the > +//# next statement (this lets us avoid complicated conditionals in > +//# the neighbourhood.) > +//# - they are of the form "if (need_resched()) cond_resched()" which > +//# is always safe. > +//# > +//# Coccinelle generally takes care of comments in the immediate neighbourhood > +//# but might need to handle other comments alluding to rescheduling. > +//# > +virtual patch > +virtual context > + > +@ r1 @ > +identifier r; > +@@ > + > +( > + r = cond_resched(); > +| > +-if (need_resched()) > +- cond_resched(); > +) > + > +@ r2 @ > +expression E; > +statement S,T; > +@@ > +( > + E; > +| > + if (E) S > +| > + if (E) S else T > +| > +) > +-cond_resched(); > + > +@ r3 @ > +expression E; > +statement S,T; > +@@ > +-cond_resched(); > +( > + E; > +| > + if (E) S > +| > + if (E) S else T > +) > -- > 2.31.1 >