Received: by 2002:a19:f614:0:0:0:0:0 with SMTP id x20csp33984lfe; Fri, 15 Apr 2022 18:07:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy691Hf/TfuCXqx8QlHfPg4N3ytyylonBCsv0QvSGHPJ1cSpkFzdcUhSc/pUHR2S/nmxZrJ X-Received: by 2002:a63:1907:0:b0:39d:4f3:6dd8 with SMTP id z7-20020a631907000000b0039d04f36dd8mr1208498pgl.447.1650071257535; Fri, 15 Apr 2022 18:07:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650071257; cv=none; d=google.com; s=arc-20160816; b=E7vL4nj/OYROSt06MxYvJdOs7De3mHStlO2Mo8l0llTIvdUbHcbJmZh++MEQXvAKPv Ub1KkMCGBspDrmhMSVb3RlnW7A6mx9PPPEmpMTtkaZ8FyDifgp5WaqrdqVgYSsH56Gcc iIWsEDpIRaF+Emz++QDEdTu4QMeafhU2lqnysaSUmf64hshnsY+PrcWiwyfWrSGC8xxW +Csg2pxzLHIJ4KWHRkeh/xzA5knEMT44Xnf0GnujnpmXaLmCnf3kWBvLoHG1k+sUNzh+ t5nq1p5HbxHupEwhqxu3G9X7qbbTZ47zttzFt21yWsAkQo2V4FN7buc3Lzhhudpgz3QI nL1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=y+P+wsImsSqgDG2hoQ67vliU1rYUIP0GkvJhsdqYnn8=; b=tPj2JRDAdFc6hRRx78bxbmhtbdleGRPrqyweg4JZJflazjRCC2fdPneos9qgPPv+JK P3oqxkK8vqnYnWBUs4ueST8r677YundvU2YwrlSlj4Let93b+K/vymJ9gNt+KjM+TxBQ f6XId6gIumkZGqEA0/Xgo1FXSnJymND2Py9JEImlo4+mK7pwy5zcdNSRZcfw8FC2fSOC NxSV9Le9TXbpTdWkz5BBEdf9ZBAYHlN8UTZJwgXfRE8vrxW1IPE9UDWRIQlkxT250l8Y 3mtsv4ttxxbgOjo6JE36ALbXRpNv2xm2tSVkJ17mX1gQw4lrRGxf3mw1+flSKqQ4F3q3 Vqsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="Nkc9/u3K"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id l11-20020a170903244b00b00158e5bfcc7dsi1381903pls.136.2022.04.15.18.07.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 18:07:37 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="Nkc9/u3K"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 90F4E1275A4; Fri, 15 Apr 2022 17:48:05 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345974AbiDNTyH (ORCPT + 99 others); Thu, 14 Apr 2022 15:54:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345966AbiDNTyG (ORCPT ); Thu, 14 Apr 2022 15:54:06 -0400 Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1862DA0AB for ; Thu, 14 Apr 2022 12:51:40 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id t4so3745190ilo.12 for ; Thu, 14 Apr 2022 12:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+P+wsImsSqgDG2hoQ67vliU1rYUIP0GkvJhsdqYnn8=; b=Nkc9/u3KfmipvAsXBmHbJh57O0BT01HkCmXuqNm1U15HVrx/Z/rKAaIdelG5+Co03N 5Xir5jQ+WN+/DdjMw8qEMHfSopdpz7mU9fOyTfg4KXevMno9m+urWSiI5V7WdRnQYCS6 28LUE0mjH+DdzbFcLSPXwgsbIQ97red8g669w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y+P+wsImsSqgDG2hoQ67vliU1rYUIP0GkvJhsdqYnn8=; b=ANlw9zgkV38hmQBG34CUj2xiiWK9g556Y5HgqRpp/M4Ht+TKAbfBecyWkpsfufyGCy Eu4QvoftqjblA/GoCYUSW6QZ7lEaJOMDaCsBCoGSS1NVZCCsbFZpR3E/KvSVTXlHWKJJ JNk4Hk3yRooeneUbuvGtsxRxV2gLHS3UX6Lo2tpQrrj3i1cOJTXMufmCTc6KOSn/Yism VPa+Mex/R4WNlaQy1TWDFPFDiGsWymHNikDgxPd6IDE0zQvzTTP1vMLfVTtUos3z+8LN BaNbq5P6WouJFd/opfF+67kbVRPv0oL4SPCh/F0szGjcPHXU6fHripG9y6oAzt8j9IhT +PiA== X-Gm-Message-State: AOAM530W3dv4aZaS5bdpGGmsVhRRQpSc5BIp37g2tztEPluJ7zGPBBrW FrHdonfAz5HdXoAP/mlcLkC//hZOR9cBefk5yU0v2Q== X-Received: by 2002:a05:6e02:1cad:b0:2ca:1e5e:80ab with SMTP id x13-20020a056e021cad00b002ca1e5e80abmr1556065ill.274.1649965900318; Thu, 14 Apr 2022 12:51:40 -0700 (PDT) MIME-Version: 1.0 References: <20220408155002.GF4285@paulmck-ThinkPad-P17-Gen-1> <20220408174908.GK4285@paulmck-ThinkPad-P17-Gen-1> <20220408205440.GL4285@paulmck-ThinkPad-P17-Gen-1> <20220411154109.GX4285@paulmck-ThinkPad-P17-Gen-1> <20220414194204.GU4285@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: From: Joel Fernandes Date: Thu, 14 Apr 2022 15:51:29 -0400 Message-ID: Subject: Re: [PATCH RFC] rcu/nocb: Provide default all-CPUs mask for RCU_NOCB_CPU=y To: "Paul E. McKenney" Cc: LKML , Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , rcu , Steven Rostedt , Frederic Weisbecker Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2022 at 3:49 PM Joel Fernandes wrote: > > On Thu, Apr 14, 2022 at 3:42 PM Paul E. McKenney wrote: > > > > On Thu, Apr 14, 2022 at 07:19:48PM +0000, Joel Fernandes wrote: > > > On Mon, Apr 11, 2022 at 08:41:09AM -0700, Paul E. McKenney wrote: > > > [..] > > > > > > [4] All CPUs are offloaded at boot, and any CPU can be de-offloaded > > > > > > and offloaded at runtime. This is the same behavior that > > > > > > you would currently get with CONFIG_RCU_NOCB_CPU_ALL=n and > > > > > > rcu_nocbs=0-N. > > > > > > > > > > Yes, this is the behavior I intend. So then there would not be a need > > > > > to pass a mask (and I suspect for a large number of users, it > > > > > simplifies boot params). > > > > > > > > Very good, and from what I can see, this should work for everyone. > > > > > > Just to clarify, what I am going to do is, if this new option =y, then > > > rcu_nocbs effectively wont do anything. i.e. All CPUs are offloaded at boot. > > > Let me know if we are not on the same page about it though. I do feel that is > > > a sensible choice given =y. If we are on same page, please ignore my comment. > > > > I was assuming that the rcu_nocbs=??? for non-empty "???" would override > > the CONFIG_RCU_NOCB_CPU_ALL=y. If you choose not to do that, shouldn't > > you at least issue some sort of diagnostic? After all, the sysadmin > > gave a kernel-boot parameter asking the code to do something and the > > code is choosing not to do that something. > > > > Of course, such a sysadmin might want the CONFIG_RCU_NOCB_CPU_ALL=y > > Kconfig option to affect only the default, that is, when no rcu_nocbs > > kernel boot parameter is specified. This would change the second "[4]" > > in my original table to "[2]". > > > > Thoughts? > > I thought about that. I feel that since we are defaulting the new > config option to =n , it is a conscious choice by the distro to set it > to =y. In such a case, they should be Ok with offloading all CPUs. If > they decide to selectively offload some CPUs in the future, then they > could revisit the config option at that time. > > I feel the kernel config should override the boot parameter behavior. > It is the same effect as a sysadmin passing kernel parameter X > assuming the kernel does something but the CONFIG option might not > even build code corresponding to X. > > I feel to address your concern, we can document in kernel command line > documentation that rcu_nocbs= does not have an effect if > CONFIG_RCU_NOCB_CPU_ALL=y, would that work for you? Along with documentation, I like your idea of printing a diagnostic in such a situation. I will certainly do that. Thanks, - Joel > > Thanks, > > - Joel > > > > > > > > > I believe that Steve Rostedt's review would carry weight for ChromeOS, > > > > > > however, I am suffering a senior moment on the right person for Android. > > > > > > > > > > I think for Android, Kalesh Singh is in the kernel team and Tim Murray > > > > > is the performance lead. They could appropriately represent their RCU > > > > > needs. > > > > > > > > Sounds good! Please collect a Reviewed-by from one or both of them. > > > > > > Ok. > > > > Thanx, Paul