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 C1286C10F04 for ; Thu, 7 Dec 2023 04:17:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E21D36B0081; Wed, 6 Dec 2023 23:17:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD12E6B0083; Wed, 6 Dec 2023 23:17:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C988C6B0087; Wed, 6 Dec 2023 23:17:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BA6F86B0081 for ; Wed, 6 Dec 2023 23:17:33 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 414DBC02E5 for ; Thu, 7 Dec 2023 04:17:33 +0000 (UTC) X-FDA: 81538713186.12.11E2323 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf08.hostedemail.com (Postfix) with ESMTP id 5A84E160009 for ; Thu, 7 Dec 2023 04:17:30 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jURRJuZ9; spf=pass (imf08.hostedemail.com: domain of "SRS0=pFZs=HS=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=pFZs=HS=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701922650; 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=wO4oUG+QC78rAEYOJfFdwwCXUa5IcAsEb7T1sKZHqtU=; b=ENquJ4g9FVZ8Mh9yt0TVlcnjRWacBio9sLKSBP7pUQunBVdr+VOXljIX8y+sYSayvK/w6u 8tP9/Ff2CvsM0zTU3KpeTNJykOCJcOPSkAEXR6jpdRt6MtV9+n8rIiBggU/Wla5eN00UJz xEGhea7uOpY4Dx9Xpq5oQ1SRNmD31L4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701922650; a=rsa-sha256; cv=none; b=AZ419TSLzjaYfgjRYsdrYd+212Y3PXLyOnp9PeavmHwCyH1OnJxONCSi8vv8XEeWOOsg14 DNY5Y25E1Pkv2QdhO6dekeL42KesbeCPPlWzkWM/eruTm9CCjD2RxpYsgTNApkFE/Owme3 YvchM5B95xKegzmxYKJ2Rk0psMBZa64= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jURRJuZ9; spf=pass (imf08.hostedemail.com: domain of "SRS0=pFZs=HS=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=pFZs=HS=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 02CDBB8259A; Thu, 7 Dec 2023 04:17:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CB3DC433C7; Thu, 7 Dec 2023 04:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701922647; bh=T+v7xQvdCpJ6DcfwiigwsZNAAWWbz1JSdHy4eCuWWWw=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=jURRJuZ9+VEQSNiJ/mGla8BQv99HITnl1MpanDWFC2m9APywmIaCm1VQb5IBXnci7 OUPfxAad85Y4t0bnci3B4FgmTeCGmMFBnMYAvDQZfuYDW38Tcgd+QjJTLik9bBPBzJ HsP1fK/y3SLK7zzyi/47+cmMVusOngCr5ILZ6MPSyvYWLtW4OYk3mJdv2jE5wk2Lp+ jOudlCHnHXKjAFTN0qjFOA8d7czNjckrmNrOCTXg2qd0Jeo2L3Xy1SXJljfFPioNWQ tx7r5rq/RFBJVNAry21GXxX7LNfYZMMCRLs4+fFflB+EpSXrAIPFabnDn1pfVF6OdN 4fh4qiHcD3bUA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id D7EBFCE0E88; Wed, 6 Dec 2023 20:17:26 -0800 (PST) Date: Wed, 6 Dec 2023 20:17:26 -0800 From: "Paul E. McKenney" To: Thomas Gleixner Cc: Ankur Arora , linux-kernel@vger.kernel.org, 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 Subject: Re: [RFC PATCH 48/86] rcu: handle quiescent states for PREEMPT_RCU=n Message-ID: Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107215742.363031-49-ankur.a.arora@oracle.com> <2027da00-273d-41cf-b9e7-460776181083@paulmck-laptop> <87v89lzu5a.ffs@tglx> <209f0e89-7ebd-4759-9883-21d842d0d26c@paulmck-laptop> <875y1bwen9.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875y1bwen9.ffs@tglx> X-Stat-Signature: x88sgghtpn7jfbiecdrs8ft5hsptrrj7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5A84E160009 X-Rspam-User: X-HE-Tag: 1701922650-74581 X-HE-Meta: U2FsdGVkX1+OL/5BLqxemC87AidtMgpW9EHQi+JF25FO8mktzcZP9A38OXaZemOJbwkTn+T0+O4PVNER8MXAC7nE5vcSK0UpMvVLPuc85YkXy3AZ/kLhxG665fT6ASgPSZHy0PJOUEXQzJGC3uR/C59Re/5/UilfNF3XIdkUBD4alwECiF3pNP3IO3OZlYu2P3n8H9U97ufmo6yOk9YtMBCtL8BHwHkCEq2ELlzeQHTr86vFplkAKrneoF2Vx4cuvQkNuitSEumIh3szqS/c3nTeRdbCXI/BIAPh4IO+qgndgPi16kII+otNd3S4qmpOb1WxOKo38Q7m5oN1bXQgbo5HVRnzNttjP34WkyJ2xiz/I+Od9OpvSYr7nhpalnbtLCYLPqT61TSxdILrhkB3NfrqE0nYat3I3rs6x4hFel8qY6XA22Jh32DjBwwAEqKsvIYRlybG5xJQH8o5vOGqyVPr4I4SO02Ol96ndtL2hU2SNcfcl8Lz1So2ZbTr2PrX8RXQQ9rOSZ+q5t3sMFu7WyncC2uzMVa43Qu1YNEJX6vWc5iRs68T0SeoXWEyOaLok1xaeqpROmZ9cH/6AGS/ZxMgDXjGYKCV2/AArqiVbYRf3ZLoOP6XwMkNFgKJxkMzoMOB+uGkMT2VhCgDoPFdttAULJ5xnvVkQ+3jrwwXFVrVNcwyNXqpJZ9kxpdyjVTleeqpVx581DTCIVgH9dVfHJmZzsGuxIGJoHod2Kf2KwrhyiRD2XfZAwpppO/6GctAi3MB1IeRek4M/xCBhub7Fv/gzt099apKiqr5CjUmGVA/4Nrq2GydI49MlBNrlAaegjVXhnoOjmCi3tPnBLwFjdeehHrdS7WlWzMkw4T0raCGfulqxqcZ8Bk1wxedq/xMZ/rFdNEUxfyKOaKh9ky75fufwwHWqqNThXJS4xRrA1WPpuBEBdvnx76LLasw0DC3tGMks8E1Kpbrx1FsS0E rbop7G9A 0oi6RQQu/C406+5hvx5LsRxA1zYzmWSyFCPyEUMiRhInmmX35fXRhdjOfvt2aNBCI9MqrHdUbWSe4KbpKU+ACT7cfrtSFWA/6pDNwRSoQTA3VCQYnWhAjI+tEBjntbHABH8yNmVhQvbox9N637FDgeg1f+DeYM74BcjkKxe8Usi/iWvQLDqpQqj0sUoIjMfqSiGNakorclnZIvg8MjcqZyHTjYla9nPmJYxbXhGiKeoy5mt9CWdewBqY7+agBoI5AZlHrxyz6ep7yeMWiVUlg7irTFhEWP2ymqxaLJFhfRyHXZVWju5+1Q318zJA0KVBqAiNyRp53OWGXo5w6VVOPdZOSR0R2r+wnBmhRR0sz8GGCqGPTsX7A9UakE6lceSGOd3bBMmuumgHNvkIqjulu3/fT97U3hu5rzEiGvhrUBKPI9dZfZ+Qd9xqbt/vaNk3HD1b+vqy9UyYli7E1/OkAnBPbDQpyJcHHh/P9J7Z3U2Xg5X+0bHyuJm4I5CN1Qg0W1NebRyNtxKpexM51ryl1Yzl6n8cdfKKGe1KH+xk39ZES2Wh7f+EoJsKvhFixMrYs/4Yyob2Mm0JZYpE= 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 Wed, Dec 06, 2023 at 04:10:18PM +0100, Thomas Gleixner wrote: > Paul! > > On Mon, Dec 04 2023 at 17:33, Paul E. McKenney wrote: > > On Tue, Nov 28, 2023 at 06:04:33PM +0100, Thomas Gleixner wrote: > >> So: > >> > >> loop() > >> > >> preempt_disable(); > >> > >> --> tick interrupt > >> rcu_flavor_sched_clock_irq() > >> sets NEED_RESCHED > >> > >> preempt_enable() > >> preempt_schedule() > >> schedule() > >> report_QS() > >> > >> See? No magic nonsense in preempt_enable(), no cond_resched(), nothing. > > > > Understood, but that does delay detection of that quiescent state by up > > to one tick. > > Sure, but does that really matter in practice? It might, but yes, I would expect it to matter far less than the other things I have been calling out. > >> So if that turns out to matter in reality and not just by academic > >> inspection, then we are far better off to annotate such code with: > >> > >> do { > >> preempt_lazy_disable(); > >> mutex_lock(); > >> do_stuff(); > >> mutex_unlock(); > >> preempt_lazy_enable(); > >> } > >> > >> and let preempt_lazy_enable() evaluate the NEED_RESCHED_LAZY bit. > > > > I am not exactly sure what semantics you are proposing with this pairing > > as opposed to "this would be a good time to preempt in response to the > > pending lazy request". But I do agree that something like this could > > replace at least a few more instance of cond_resched(), so that is good. > > Not necessarily all of them, though. > > The main semantic difference is that such a mechanism is properly > nesting and can be eventually subsumed into the actual locking > constructs. OK, fair enough. And noting that testing should include workloads that exercise things like mutex_lock() and mutex_trylock() fastpaths. > >> Just insisting that RCU_PREEMPT=n requires cond_resched() and whatsoever > >> is not really getting us anywhere. > > > > Except that this is not what is happening, Thomas. ;-) > > > > You are asserting that all of the cond_resched() calls can safely be > > eliminated. That might well be, but more than assertion is required. > > You have come up with some good ways of getting rid of some classes of > > them, which is a very good and very welcome thing. But that is not the > > same as having proved that all of them may be safely removed. > > Neither have you proven that any of them will be required with the new > PREEMPT_LAZY model. :) True. But nor have you proven them unnecessary. That will need to wait for larger-scale testing. > Your experience and knowledge in this area is certainly appreciated, but > under the changed semantics of LAZY it's debatable whether observations > and assumptions which are based on PREEMPT_NONE behaviour still apply. > > We'll see. That we will! Thanx, Paul