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 4F2F2C197A0 for ; Tue, 21 Nov 2023 00:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 633F96B0334; Mon, 20 Nov 2023 19:28:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E4426B035C; Mon, 20 Nov 2023 19:28:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AB6C6B035E; Mon, 20 Nov 2023 19:28:56 -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 399D46B0334 for ; Mon, 20 Nov 2023 19:28:56 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F2F3B120113 for ; Tue, 21 Nov 2023 00:28:55 +0000 (UTC) X-FDA: 81480076230.19.BCD97CA Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf02.hostedemail.com (Postfix) with ESMTP id 17B668001A for ; Tue, 21 Nov 2023 00:28:53 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aPBqq9i7; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 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=1700526534; a=rsa-sha256; cv=none; b=HLFwrGUpnq9YZeOdw0Gj1//iAe3y1Inq7YMpSangLaLs1tSDTRymQts0RBwxzqrfn+5Xf2 ylem7LxdXYu1WvojRtgav0Lr2G+YyGqaD8Ojinnf3YAH/fY1d/PagfXZGPbJZUmRBX9Wef GW1JYeR28TJJRq2CgayZZhaLrsL9f60= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aPBqq9i7; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.68.75 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=1700526534; 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=XwuDrkvlDLBHfrIy53C+s+mn7gFT2Trl7ro0yHu9l7s=; b=w4c62TbzcBol7Nm2dycU3ijSr36XTfGIZWikT+tFAkAOGEhdFuyjHcMi6tNS5Me97kBs6t awI04Wstc63Kj8LtKMqmyMkDtSY3Ex7Hf774qXqkuHI5gsuON6UXMblnTIbRFX+pe7Tdgu DhH4apSNVSwy6IZvQBFtSbI4U1ydc48= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 21AA3B81C08; Tue, 21 Nov 2023 00:28:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F2D5C433C7; Tue, 21 Nov 2023 00:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700526531; bh=tVOIKJd4kJ7fBg79SOhSnFST6k3zeeIVN5WaqodLUIU=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=aPBqq9i7I2H+gEkoVoqGZAeigotmYTn9NrtyDRrkVpdPb48U7gqp41xPVdezq2b7v mefnJIVi7ZTa+tv+ezKbK8qMRK6WubXgofQPZQGEq4cips2WkMjhe0g+wCc1U62BzH Q55vlOmcwDarqnGOx7C53FvXxhucy+ZpCa/x2SW4O5wD+52NAzb5Jt5RM6hsjLrjYL FShMcdRAb0ciBB18Ssx9ie9Qa0VfagAuGyU+lNrx+22+MTxIZoLMABQHWel/1fKylt FqwQasqRaGTL5e5kNJEXRIjiuaX++ZtLp/LgNELIQsOZ+Prewa9EoW9jHgtTOcN4hG 7ey954nDYv+5A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 0378BCE1ABD; Mon, 20 Nov 2023 16:28:51 -0800 (PST) Date: Mon, 20 Nov 2023 16:28:50 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Ankur Arora , 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, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Simon Horman , Julian Anastasov , Alexei Starovoitov , Daniel Borkmann Subject: Re: [RFC PATCH 47/86] rcu: select PREEMPT_RCU if PREEMPT Message-ID: Reply-To: paulmck@kernel.org References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107215742.363031-48-ankur.a.arora@oracle.com> <20231107192703.1c493431@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231107192703.1c493431@gandalf.local.home> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 17B668001A X-Stat-Signature: cyi14x3wkjoecnu3uzcoxna6pjq8jcj7 X-HE-Tag: 1700526533-36323 X-HE-Meta: U2FsdGVkX18JUuYaFEGS30CnnPMHBSRlW1UQp9j0/4QW10ttHMtHtsfjIuCuiiOKYlnFQxjMZPifvQR+Wickq2HGjezFX32riBcZgfkwui1Qvjigxa+lNz7/oOA1+yv6SqaAJFjj06tOBmMLH7+Dy77o5lPRQDwoLtiEmqMZjOy5rquM6QyBo7DflqBsIRw0xNE7nJlorPhhuz7J9VhttoYpSCUXlbI2YgX+op5aFuQ/60bVo8cdRaq4j9LYWg+HJPPGAiIN4htOGnZavPXcuYmSENzGR+AED5NRI+ivzPEti38xDblzYg+EJW5NweDDHzF8Lp1P4sE208s6VZ7JZxpBMXPjb+8M59sZWC8qmegGJ84tEVYqkTaNILhxK8aXCZCZ7z7x8yQ5I2z+6MMFpJR98CtkziE1GIdUl+G/Ax2llhSgDWjDL8+iDrCxxg1ff1MVCaIUHeCmXCo7KBL2VelN7ebFIC2+HwsZ/AjggDdLTibw2gvQEPud96q28wdIKye42j+ReH6xeUCVIjcxwWTMQuEc8rqWzVkezVGuwVflbwe16xc1KxTsv09DihYkbD9fflBAIGjEIxezXfeYI/t3uGU+EEg+8t34IhYK1oqbS1+yE58+DHNWM6RPkjHe31BSsZ+9BFX6oAJNA1k99p41XCld0uNOKb7SFkz6XSuCwqLmLoC52C6ALT0X5DdZXGff+pMF9CSxbvKrFo9DSsu21xk0J3aEmQn7FwPqyfp3iwS6CpaiaTMElY/bz5oB1E3TerDAW/sXEZomQQx31fzuUBGmVB8RYC7WP8O9WmDqvHvjlzQ8P4k97e6nPPWyI67VXwQXk1ZNtX6PL27yyMcds7bLapOoqY3CXl4wMp2ZMXCSpSVom4qVvnvGBKcLVyPVlfOsN6b+CTBZ8U0oD8zlsSh6VoHT+quLhV23DJMFJ5WEG9zZQoseJ5Y1oemgefhbiBtWi/b7WM07NhE RltU5goq sVWBx1FSMuXcOV3pftvRteaw7td7CgZEmTtLnpq5Al29+7pL712fF9AjDnabGyXQGYqUL9/sD2nruRHb8Cmu+q9l+NHSewLoJAKhUGOyw7vAj5Ktxnk4rUeMLoX2kdD0qkC8+XqGSnW8xMlpQkbsExsRmrq5ufBBY7q/eSBHB6LGO9myJyiXp98fQLDCDNsGzGhs3rdc+PU4Z2eosKBOeLXiJNsFuIJJNyepF+az5AHAHu0yDV3EGNjAjKGeFbjYquD94rkmS+mDAhY8R9TwSJc7txnerovQ7UtJ8AkKBxw/lvTC8+DcvjIyzTXbgDvvYeh9d0b6zb9jfmTsauMbAdC/kCcKsFe65Ey1hgN36vcFO2dm7rd997Z+vyMV35IYNG9yqOTuR44AXPFUh66KMJ5LOhceZcs3kIzmRSLIDUjg9YHN74g7tE49LZIzfNOw5+noXtxcC98bNFxikzLB1I3UjGNd1ojXL+4vbd0KOnvUj0DdWM2guttFP7sErhzSMJz329+P5pT3hc9zN2JbFjL2ujr38TveioGh18Wih7K8OaFd6zm/nc7WsHfP9yheDdHbfklYManhpoluK8qy2sqFueeNcWpSAOQjo 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 07:27:03PM -0500, Steven Rostedt wrote: > On Tue, 7 Nov 2023 13:57:33 -0800 > Ankur Arora wrote: > > > With PREEMPTION being always-on, some configurations might prefer > > the stronger forward-progress guarantees provided by PREEMPT_RCU=n > > as compared to PREEMPT_RCU=y. > > > > So, select PREEMPT_RCU=n for PREEMPT_VOLUNTARY and PREEMPT_NONE and > > enabling PREEMPT_RCU=y for PREEMPT or PREEMPT_RT. > > > > Note that the preemption model can be changed at runtime (modulo > > configurations with ARCH_NO_PREEMPT), but the RCU configuration > > is statically compiled. > > I wonder if we should make this a separate patch, and allow PREEMPT_RCU=n > when PREEMPT=y? You mean independent of this series? If so, I am not all that excited about allowing a new option due to the effect on testing. With this full series, the number of test scenarios is preserved. Actually, that is not exactly true, is it? It would be if we instead had something like this: config PREEMPT_RCU bool default y if PREEMPT || PREEMPT_RT depends on !PREEMPT_NONE && !PREEMPT_VOLUNTARY select TREE_RCU Any reason why this would be a problem? Or to put it another way, do you know of anyone who really wants a preemptible kernel (CONFIG_PREEMPT=y, CONFIG_PREEMPT_NONE=n and CONFIG_PREEMPT_VOLUNTARY=n) but also non-preemptible RCU (CONFIG_PREEMPT_RCU=y)? If so, why? I am having some difficulty seeing how this combination could be at all helpful. And if it is not helpful, we should not allow people to shoot themselves in the foot with it. > This could allow us to test this without this having to be part of this > series. OK, if you mean for testing purposes but not to go to mainline without the rest of the series, I am good with that idea. And thank you to Ankur for preserving non-preemptible RCU for those of us using system that are adequately but not generously endowed with memory! Thanx, Paul