Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6883652rdb; Fri, 15 Dec 2023 10:46:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IHJbz7XLbqk6BPPOOmAraqY5OPlrZow4ZHXwggVbmSccCmhd4M/ULiSX9XJ/7RMnvQaI4IQ X-Received: by 2002:a05:620a:1004:b0:77e:fba4:3a24 with SMTP id z4-20020a05620a100400b0077efba43a24mr13920760qkj.122.1702665979695; Fri, 15 Dec 2023 10:46:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702665979; cv=none; d=google.com; s=arc-20160816; b=qj/jWcukvq3sYULcl5Pxaqj2kKss4XJyfquha/HSp31+c8smhvXKUeodNVsGfx2RSh Xaix2a8SSbF4TgBxBaJhw+dm/0ICrDQHdAlN20UK7Svq6WJ2/GCoOaDmrkrGdRGMqJGA BY7ZHU6haF9wfDEZ21lqJVzgUre1nmSxK6I/N4xBuv2u1Rm0n82DKL4o1594KpevhNZE 3qtycou7Yo7a6mSLDxhEx07jc6RbAmw6LDkuGK7JicvoSfTWKlpPAnUp4hF2ohSFI+a8 4w1rkgUx60BnDdQlGcaSSUddE2V0HLXd+kd4xSKijV32W9Z+DvFjFijTBE5pM0w3Py/s 7Gtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=DlC2nbenMBoLOxWrJvTHdmIY6spodWJ2GpoR+Wpgr8A=; fh=tuw40IowxGZqRt0j2kAam8O+TZ6fRcxoyCtGcygwru4=; b=XBe3mdcYoQWQuFVcGJWHP6jgr1pOWw0uASvqoef5ku9YARW7JYIRtxpqRTl2WDcxaY iLhKdO+uiw2bU5gt59LQh/OP8ArN0ndNg7CyN7Hqh0FOxzeoPieKWJ9sN2AZuisH6xiN vFWQ4tC7dt1UgCF2FmzWGtwysNzdQuU4m/hE/WKN/uo8+0nAPUyKFNvXZTbNzbdJ0vJd MYurqFu6tbK1eSDhKcaw5AHkyhIgZkdUQi/fKaPWhE3HHj3zf4ZXZvDsPBelfTmJ0zku jX741HRRcJH9cGVk6KC1c3P0kMuOoKkq6TEoEAWsbDhJOVT7eWoJzTUcWTjIc0w3OOEd zGUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=h3wAzoZX; spf=pass (google.com: domain of linux-kernel+bounces-1540-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1540-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id bp44-20020a05620a45ac00b0076d2a4328c6si19269276qkb.298.2023.12.15.10.46.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 10:46:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1540-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=h3wAzoZX; spf=pass (google.com: domain of linux-kernel+bounces-1540-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1540-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 608B41C23E12 for ; Fri, 15 Dec 2023 18:46:19 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 458F53D3A3; Fri, 15 Dec 2023 18:46:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h3wAzoZX" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 772E030104; Fri, 15 Dec 2023 18:46:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6BE1C433C8; Fri, 15 Dec 2023 18:46:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702665971; bh=OtlO0KkedaO7LhwO41A2L9qyGmNp7WBBB4K/0wdOAwA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=h3wAzoZXpKfFodpY8VJ7loDO7mMTsMfNsVU+CLYN0uZKOTXpyDtbZlOaJfKflgrCJ KKqyY7IwbhzfgQEpF4qyUQwsLdt7NjSJ7INWV5Fw7EQ3vVrlayaMVIoLAEc61712Uf gMrwLLRCGzB9i19PJ/Xg3vUloemMFUMkFJqSzaAr79F+ovD5s9iQghgp9YfLQjYzEN fIRQZe4SP1eHW8qMsMBtaUi1gVncZkDvRbPkK+qB8g4WLGBajVGnystrKAYhh8+YyI Gzs4q5+hDr2/3ggcLZpmah+dOF34xzCU8H+OftusJRulX8oiapDvESgWZ/2oIk4cll 9JcuuwlDxea2w== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 63023CE04E6; Fri, 15 Dec 2023 10:46:11 -0800 (PST) Date: Fri, 15 Dec 2023 10:46:11 -0800 From: "Paul E. McKenney" To: Uladzislau Rezki Cc: Joel Fernandes , Qais Yousef , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Boqun Feng , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrea Righi , John Stultz , linux-kernel@vger.kernel.org, rcu@vger.kernel.org Subject: Re: [PATCH v2] rcu: Provide a boot time parameter to control lazy RCU Message-ID: Reply-To: paulmck@kernel.org References: <20231203011252.233748-1-qyousef@layalina.io> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Dec 15, 2023 at 05:58:55PM +0100, Uladzislau Rezki wrote: > Hello, Joel! > > > [....] > > > > > > + Use rcutree.enable_rcu_lazy=0 to turn it off at boot time. > > > > > > + > > > > > > +config RCU_LAZY_DEFAULT_OFF > > > > > > + bool "Turn RCU lazy invocation off by default" > > > > > > + depends on RCU_LAZY > > > > > > + default n > > > > > > + help > > > > > > + Allows building the kernel with CONFIG_RCU_LAZY=y yet keep it default > > > > > > + off. Boot time param rcutree.enable_rcu_lazy=1 can be used to switch > > > > > > + it back on. > > > > > > + > > > > > > config RCU_DOUBLE_CHECK_CB_TIME > > > > > > bool "RCU callback-batch backup time check" > > > > > > depends on RCU_EXPERT > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > > > > index 3ac3c846105f..8b7675624815 100644 > > > > > > --- a/kernel/rcu/tree.c > > > > > > +++ b/kernel/rcu/tree.c > > > > > > @@ -2719,6 +2719,9 @@ __call_rcu_common(struct rcu_head *head, rcu_callback_t func, bool lazy_in) > > > > > > } > > > > > > > > > > > > #ifdef CONFIG_RCU_LAZY > > > > > > +static bool enable_rcu_lazy __read_mostly = !IS_ENABLED(CONFIG_RCU_LAZY_DEFAULT_OFF); > > > > > > +module_param(enable_rcu_lazy, bool, 0444); > > > > > > + > > > > > > /** > > > > > > * call_rcu_hurry() - Queue RCU callback for invocation after grace period, and > > > > > > * flush all lazy callbacks (including the new one) to the main ->cblist while > > > > > > @@ -2744,6 +2747,8 @@ void call_rcu_hurry(struct rcu_head *head, rcu_callback_t func) > > > > > > __call_rcu_common(head, func, false); > > > > > > } > > > > > > EXPORT_SYMBOL_GPL(call_rcu_hurry); > > > > > > +#else > > > > > > +#define enable_rcu_lazy false > > > > > > #endif > > > > > > > > > > > > /** > > > > > > @@ -2792,7 +2797,7 @@ EXPORT_SYMBOL_GPL(call_rcu_hurry); > > > > > > */ > > > > > > void call_rcu(struct rcu_head *head, rcu_callback_t func) > > > > > > { > > > > > > - __call_rcu_common(head, func, IS_ENABLED(CONFIG_RCU_LAZY)); > > > > > > + __call_rcu_common(head, func, enable_rcu_lazy); > > > > > > } > > > > > > EXPORT_SYMBOL_GPL(call_rcu); > > > > > > > > > > > I think, it makes sense. Especially for devices/systems where it is hard > > > > > to recompile the kernel and deploy it. For example, Google and GKI approach. > > > > > > > > My concerns had nothing to do with recompiling the kernel. Passing a > > > > boot parameter (without a kernel compile) can just as well > > > > default-disable the feature. > > > > > > > > I think what Qais is saying is that passing a boot parameter is itself > > > > a hassle in Android (something I did not know about) because of GKI > > > > etc. > > > > > > > That is true. Doing: > > > > > > echo 1 > /sys/.../enable_lazy > > > > > > is a way how to make it easy and flexible. > > > > Hey Vlad, are you suggesting that the boot parameter be made to > > support runtime? We can keep that for later as it may get complicated. > > Qais's boot parameter is designed only for boot time. > > > No problem. Yes, i meant a runtime one. But as you stated there might > be hidden issues witch we are not aware of yet. My current thought is that Qais's version currently in -rcu for the merge window after next (v6.9) suits our current situation. But if we are eventually able to support runtime changes to this new rcutree.enable_rcu_lazy module parameter via simplification to the rcu_nocb_try_bypass() function (or maybe a better analysis of it), then at that point it would be good to allow this module parameter to be changed via sysfs at runtime. Does that make sense, or am I missing some aspect or use case? Thanx, Paul