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 31E17C54FB9 for ; Tue, 21 Nov 2023 05:04:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B52B6B0342; Tue, 21 Nov 2023 00:04:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6654D6B0391; Tue, 21 Nov 2023 00:04:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52CC36B03AB; Tue, 21 Nov 2023 00:04:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 41E996B0342 for ; Tue, 21 Nov 2023 00:04:32 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1C3F04095E for ; Tue, 21 Nov 2023 05:04:32 +0000 (UTC) X-FDA: 81480770784.20.7FAE6A5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id 3A2A84000C for ; Tue, 21 Nov 2023 05:04:30 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=o6DMWnpx; spf=pass (imf01.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=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=1700543070; 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=kJj7pUh41sNNCyTIwXK1haxlnagI03p1gact25QmXj8=; b=pWkFbM9uc8DhXeqfrN/CG3mD1ra8aH2PLarp8+WsfgvCKe7j0axE6JWn6ziGfpPnTNenwU RXCIBffmGvtB5REjk1lm7hIyJhGpLq0qHlZCVr1rxHNXFhdd7BGc53Y0T9yyC0r9HD3Woo oxidPCsSKC3DDj7Bv2iyeDHJJ6+ftv4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=o6DMWnpx; spf=pass (imf01.hostedemail.com: domain of "SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=TAUs=HC=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700543070; a=rsa-sha256; cv=none; b=BNaLPqkbIt0CUgdN2z7SOakZCmyDj/P477i1xSQhfmtaME0WftjbPcVWlXlI8cuUtI/633 zLv+MIqotTd+SQDrDNI91METyblkDBx7lx5i12DT+LuaRbi5DfZCPDSOAn+oV4JI2RoBqy kKnzl/89dCRhkMYNZv9BkcL/Q06DqBI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0F55F614D5; Tue, 21 Nov 2023 05:04:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B4D9C433C8; Tue, 21 Nov 2023 05:04:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700543068; bh=RbKIbUhk3SZI+F62STbLelz0E+yirHODppjTDpyDT2g=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=o6DMWnpx52ZhUHrg41Fy2My/p6Zt1f7Si7DR6XB79UrS1xLKfqSvW9L5viuHLx4q1 lF/uoHRpysPlf8FxGGDQSWBWk6cJhEU6cOsZYSru9psW+v0SMHY8dmvDPVFpXa5UUY WJisoPLBDFa6Uj2AhyS2e/OonKxjXVwufTwSCM83k2c4rq0GhotGsu1Ni8Yu8TPurI ayqgukRJbYLv55H8eNu7cymmLSgoNJKyEwjCPfQrJmwJnZcd6D6C1lJ8+Tf+lTDQfG CABhS4yjRMmSFlWJhs29phBvx2th0oIVOc8TvsxSr//xyU3XzS0MRsFCDg64E8Oms/ hYarkN90mouLA== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 39ED3CE1390; Mon, 20 Nov 2023 21:04:28 -0800 (PST) Date: Mon, 20 Nov 2023 21:04:28 -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: <29984609-14e1-4ce4-864b-87932ba3245a@paulmck-laptop> 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> <20231120224356.7e9e5423@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231120224356.7e9e5423@gandalf.local.home> X-Rspamd-Queue-Id: 3A2A84000C X-Rspam-User: X-Stat-Signature: z6hoh9ebbn9no7cm5bnte1ajtn5uzsxx X-Rspamd-Server: rspam01 X-HE-Tag: 1700543070-179370 X-HE-Meta: U2FsdGVkX18wGmtcA3IuOynAZtjEP2oAsAfEsOF9IohNcjjy2w+2OOs8K68CzwkWCiZrtkJf0OwgTXJPFYTl01qd/vICYLOX+3SIQGF8WK8IFG3pXrOv5SQvUaA2xs7ir4ahvUlfL9iBTC/w4gi84c9f+VuO5gvXRRXXE8ekE7mAYtAclMAkBvth0gAChGHbZVWK4EzqDUUz2Gq6+cg59jsQgCuoqJBxTmUz8G1HVtWFTmWjTkNeot92nyb7dqx4Dh3jnHYR64Zf7Q4z1zMESgECrnn9JAW2EittEnnqJd5PwdLYoT0I/buSA8HCt1gViEjzT2BHhZejnbiJR7DH9tFEaxW0ntm/AWh3j+yl7X9OIUQjp+CJM272duG3YXiDajTdEkuaWMsaF8XjZtP1nFOn8a69xVmws4GYNg4/TXLvpgMWE8H4JH5V57Otm3mRPwKk7tcrxRAvIt4Pakbc+BAPvGdJKgioQphCeMt1XPqzBa+HuQ/IkOvONUoDoqW4GlLC8TnxMk51pcnby1I/hvvXvCzpzI7ZNTUTFzXI1Z49/7ZEG96BxMldSdZhYFuQCiG7aGoiK+lqzF7tqttWtsZKppDsE48vwpwhUqeB6PRCeFeKUTkXHHTm8pCL60DYAmGL7WveUzg487kR+8xhfY7FGCVFtJF012qvvlnWwfQZpdX/SSZ/C90RdwNK+OyKWfzLZlT5ambfm48bluYi1t4Jh8RQPI6exhlt5v6IUh08Mvulrk0Mmc2gL37xJbHh8YUjtTsA2Z7zncp1qxXkVUNB6wVIQmM/9F/YjpCeZX7c0rNGimayV60f1aSKsDTxx8Tapu6uG0mZVb/rte9RAODf/dPGMuLiK5HWI3/JAnGM0v2C16By3t9wxzcmICH3MZ/Ri0+HPHuKsrm0x8Kn7GJzv8B2jxmBNenSMdqFkUUeejmwKhptYkQ4RjQVHOI6Obb2O3lkQYB92evRO/0 /6z+vpU7 r6+H21b+5+kQkOXBSr9DdibFTQlP18JWkLs2iT7DA7cFkcig5SWR3UmUnxH17EBQ/FRJvNr9uZu7GUuBgpGOMhH5IdqUulhzoQC7USIekN91qhyiQOm9MTykjKevYdMj0JLA2QDmNgdecUbBAmt9b3YIgd1gtEFKTtA/rqaed1XIcXpQQcfmFR5nrio7LiOL+/F48e5n8Cs6L2eVbcC9kMirtMi4Zc/Dm+oYis+4LPT2+wGDyubXEBAMeHKHkz0ESgYf0ueq/yOBWWOBGQMrLvYtR72Nh2prmNLXez65OLNieIeE0pPmxLcjxQjes4cSdwCEgzThAy3gGokih4Iol97U82i+iM5JULj3+dvxMkKbLyTqLwIj8Olwaqdk8hoCg/PTrljuQgXPqDAprzwNAlAtPkGNyoyKgtNvTY+5tZJ8TrpaPOfibKdn4uevjw8BZzkot/F18eEpWp7aG9Kx4H3lo1TWx/+D3HN/0JAtvW+qCkKV91tQXToqeBHk4V/uI8ZFl8UESGNgekebDc0XufoANsNTcwMLLY88qL0E1SbDMYOnNEzK6yN7z+waGO+lJFZ9PI+3OXBfCyirRr7i6FyHHTV4bJuDcxduhe1gOmXCq1GErve8lSrrw64NhIMP2tTJA0jvEC4F5XovrIzKwoV+V/RvfqZaMeYvE 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 Mon, Nov 20, 2023 at 10:43:56PM -0500, Steven Rostedt wrote: > On Mon, 20 Nov 2023 16:28:50 -0800 > "Paul E. McKenney" wrote: > > > 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? > > Yes, because with this series, there isn't going to be PREEMPT_NONE, > PREEMPT_VOLUNTARY and PREEMPT as a config option. I mean, you could define > the preference you want at boot up. But it could change at run time. I applied the series, and there was still a PREEMPT_NONE. Some might consider the name to be a bit misleading, perhaps, but it was still there. Ah, I missed patch 30/86. The idea is to make CONFIG_PREEMPT_DYNAMIC unconditional? Why? > > 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. > > With the new preemption model, NONE, VOLUNTARY and PREEMPT are now going to > determine when NEED_RESCHED is set as supposed to NEED_RESCHED_LAZY. As > NEED_RESCHED_LAZY only schedules at kernel / user space transaction, and > NEED_RESCHED will schedule when possible (non-preempt disable section). So NONE really is still supposed to be there. ;-) > Key: L - NEED_RESCHED_LAZY - schedule only at kernel/user boundary > N - NEED_RESCHED - schedule whenever possible (like PREEMPT does today) > > SCHED_OTHER REAL-TIME/DL > Schedule Schedule > > NONE: L L > > VOLUNTARY: L N > > PREEMPT: N N > > > So on NONE, NEED_RESCHED_LAZY is set only on scheduling SCHED_OTHER and RT. > Which means, it will not schedule until it goes into user space (*). > > On VOLUNTARY, NEED_RESCHED is set on RT/DL tasks, and LAZY on SCHED_OTHER. > So that RT and DL get scheduled just like PREEMPT does today. > > On PREEMPT, NEED_RESCHED is always set on all scheduling. > > (*) - caveat - After the next tick, if NEED_RESCHED_LAZY is set, then > NEED_RESCHED will be set and the kernel will schedule at the next available > moment, this is true for all three models! OK, so I see that this is now a SCHED_FEAT, and is initialized based on CONFIG_PREEMPT_* in kernel/sched/feature.h. Huh. OK, we can still control this at build time, which is fine. I don't see how to set it at boot time, only at build time or from debugfs. I will let those who want to set this at boot time complain, should they choose to do so. > There may be more details to work out, but the above is basically the gist > of the idea. Now, what do you want to do with RCU_PREEMPT? At run time, we > can go from NONE to PREEMPT full! But there may be use cases that do not > want the overhead of always having RCU_PREEMPT, and will want RCU to be a > preempt_disable() section no matter what. Understood, actually. And as noted in other replies, I am a bit concerned about added latencies from too aggressively removing cond_resched(). More testing required. > Unless we can switch between RCU_PREEMPT and !RCU_PREEMPT at run time, the > dependency on RCU_PREEMPT tied to PREEMPT doesn't make sense anymore. I strongly recommend against runtime switching of RCU's preemptibility, just in case you were wondering. ;-) My question is different. Would anyone want PREEMPT (N N above) in combination with non-preemptible RCU? I cannot see why anyone would want this. > > > 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! > > Exactly. It sounds like having non-preempt RCU is agnostic to the > preemption model of the system, which is why I think we need to make them > disjoint. How about like this, where "Y" means allowed and "N" means not allowed: Non-Preemptible RCU Preemptible RCU NONE: Y Y VOLUNTARY: Y Y PREEMPT: N Y PREEMPT_RT: N Y We need preemptible RCU for NONE and VOLUNTARY, as you say, to allow CONFIG_PREEMPT_DYNAMIC to continue to work. (OK, OK, CONFIG_PREEMPT_DYNAMIC is no longer, but appears to be unconditional.) But again, I don't see why anyone would want (much less need) non-preemptible RCU in the PREEMPT and PREEMPT_RT cases. And if it is neither wanted nor needed, there is no point in enabling it, much less testing it. Or am I missing a use case in there somewhere? Thanx, Paul