Received: by 2002:a05:7412:40d:b0:e2:908c:2ebd with SMTP id 13csp157907rdf; Mon, 20 Nov 2023 21:08:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IEZKF/4C7sECvovFw9adhtPD0TrGQ8WfPMoNrpPpvpbngUE6KyrLp1Pgc5DuqtrbBlvMpX3 X-Received: by 2002:a05:6358:248b:b0:16d:aead:f74f with SMTP id m11-20020a056358248b00b0016daeadf74fmr4325235rwc.13.1700543300225; Mon, 20 Nov 2023 21:08:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700543300; cv=none; d=google.com; s=arc-20160816; b=Zwme4G7wKTa/p+GnpL4jWDZYzZk+dO/0ar0vQlIjzCpBP7UuQ4qFzziK25UlawkMA9 8VkbFM1fTThaa3ROjzhvc7JSiBfS2OqAu2q1ULqDik602snrfevf+HiPmGn4dNIQJjSc 5Sstzyco+k4uDYrYJgRjPAjeHuJhGf8c1oudXLgH9z4laHWtHzy6PqbXWCiltv9IrV2g g1LyCtKkMyAO5I3JbT0M4KqdfXfAInetCOsagFs1MseE82pRNMGVf2C0wRHq4eLkx94z TkmhTSzJ4pjyAlzR+Gts9gri705P2h8MGfUxW4NrBxHaTcdkKmcqOJmVfG8lKUlMV5VN nd3w== 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:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=kJj7pUh41sNNCyTIwXK1haxlnagI03p1gact25QmXj8=; fh=jQ5Uc6NedxhwVy8rI3uh14TYWZm60AMG6naPW/YDlGs=; b=TG4QU2ZrnfNdXv8JmnXFZARPodMwDM1S6avZv6NvrcLA62qbXe1iigF8XoT2NCrCLT eJu+1ho+POYIOmVRzwYet/jsh6LtSmync2x8mtiYfwiH05cOPSWGbKzJdLtP1KhwehSy ho9+2rRTmbjLwZ57WlLaF/KfI2fPFQWXsRu0H/Zmslix3hXrLm2Ual18xcPiUjT1tXEp 4FV5jYLRDq0BaRdHk6firlCiJT4gZX7M3i9x+asks27eO4/xF7IqZ3FEmd6CnKQCXqwm Y853Eea3qe+8F2ROgfGjjn+7mYKOobLRlsni0wKN7Ja2Vlywi5FboK4NH4YLL2PO5xXC qiYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o6DMWnpx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id 1-20020a631041000000b005bdd76219edsi8914816pgq.675.2023.11.20.21.08.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Nov 2023 21:08:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=o6DMWnpx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 9858E8082DE5; Mon, 20 Nov 2023 21:07:28 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229618AbjKUFEe (ORCPT + 99 others); Tue, 21 Nov 2023 00:04:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjKUFEc (ORCPT ); Tue, 21 Nov 2023 00:04:32 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 308E2E7 for ; Mon, 20 Nov 2023 21:04:29 -0800 (PST) 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-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 20 Nov 2023 21:07:28 -0800 (PST) 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