Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp108587pxb; Mon, 11 Apr 2022 20:15:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdQHsE8qbFUqCZO4cbkrOg/Oxd9MVAnrklZH8CKkYxj91I5RJZ6SOS/QHkn90HJanHQ6cz X-Received: by 2002:a17:907:97cc:b0:6df:83bc:314c with SMTP id js12-20020a17090797cc00b006df83bc314cmr33038543ejc.587.1649733345078; Mon, 11 Apr 2022 20:15:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649733345; cv=none; d=google.com; s=arc-20160816; b=AUpHDIjl8SMs7j/uWCvW00z5qhEebHUoKVoVupm0tqhjjorkXJMa8QM743uN0qxHys q9uyGoXYuk76Jrcw+9PofRmCHgkb39SoHh3knGkVvKk2M858u7q8qV5Z9g7Sue9Oshdy KWb9kHiIj8rzhuZxPVHAFX0UNrqLgO9nZ53tiznttacjx3dZ8nlBU7snyF8Tb3LtX+YX /nntye18gVjN771QrQLC6feNsMZVc2Wh4lDcl197IWKzuJ0bK9B06iOkAo/a4S4eplbi 5Fa9AUzlavKQ2DmBs95n8UlO2q0g3SoKfMCRMa1mNixD97venXSBzBihcjykCNHRHUBQ HOeQ== 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=/bOnxhvyFu1KFDIwI6ndnAclb7ZxIr/6CV1yYpf1Bes=; b=w+6duYUNKHHRM18uwl8ba6FGDnq0GozvzdTgGt6WsRUmPNPoXdpF80IezBuXawjB7D iFuCa47mB1+nc3Lo4l3b4Zp/devFo7TU9vgvtXwOBJYq6+snxdLDMiYrft9E76YfVQbQ dIsdYBwNK/dAhcfyzhZofviWyh1Lr7A3gEc22us5iNiU5MrkKnNsHmxAJklfAOqmMDzR d/FaD3EEdDZlt0f1CSLE0PWITB/52qC9FLzh/PLxv/nOmKNKoue2XVBfGILgaQXzRBbF ldvWkZ48H814lQcAf02NBvO61aS8nEjoUeo8RWIj0RN1ULEmTjdk3Ou3WTvPhJegoA/b 0W6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=GB26TYrS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id zm9-20020a170906994900b006df76385e45si1895070ejb.741.2022.04.11.20.15.20; Mon, 11 Apr 2022 20:15:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=GB26TYrS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231186AbiDKPT6 (ORCPT + 99 others); Mon, 11 Apr 2022 11:19:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238081AbiDKPT3 (ORCPT ); Mon, 11 Apr 2022 11:19:29 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4D5232987 for ; Mon, 11 Apr 2022 08:17:12 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id 125so19025952iov.10 for ; Mon, 11 Apr 2022 08:17:12 -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=/bOnxhvyFu1KFDIwI6ndnAclb7ZxIr/6CV1yYpf1Bes=; b=GB26TYrSINxhGazbfecUKbKOvRBG2h7WaiDZsuS7zDIBqERDKFCdOm/nTh5hpQtnkX jpDRGuYn80BIPZ8F/X+Hke7RrUGztKcufbIvpVXV5dJPiqUGFkpRxHuAPyMcPXjsRk2c g9Kiqhu5xUG10VFg4fa8ydlaiMVfRgY/cLEFI= 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=/bOnxhvyFu1KFDIwI6ndnAclb7ZxIr/6CV1yYpf1Bes=; b=JkjQgk8dQ4vYvGa5ZKNYnnqjtXu4dbqxtTubeKisLZIZLqpjr1MbHTNkmWw96Q1sOO fAyvqlIRmOdx2kiX4HGyt+A95BJwaHOLH+D7WJg/XmWBmvt0n/catgsTecR9MsK5vWwv Tto6FrS6rFPKoKlpr8Y1UcLoxZ+qvK792+S6JMJv+pYTmvfhwB0nOgEoxOjaf5dd+OT+ FsqnE7pPubxbp28r/OxyNvMeHmvDIbBc3BUeoc2un2p2gdy0SY874aqROyf9ltm0i/fK eneJb+nKSvWcWXYHaEvXkheQlTcG2RXhPO80WI5gRJXQZbwW1ZfPeW12rz3m/pptZ6nK ULBg== X-Gm-Message-State: AOAM531vO2G47NQ8+fdF0Z6BBW8cccEfP7KbsIj8yVr7wiBcVD0IXA7F mhqz25OVcOGGNmwTt057XHE71U92hhvTZzbjle8qHQ== X-Received: by 2002:a05:6638:240b:b0:326:bd5:8a6f with SMTP id z11-20020a056638240b00b003260bd58a6fmr5484217jat.52.1649690231585; Mon, 11 Apr 2022 08:17:11 -0700 (PDT) MIME-Version: 1.0 References: <20220407210734.2548973-1-joel@joelfernandes.org> <20220408142232.GA4285@paulmck-ThinkPad-P17-Gen-1> <20220408155002.GF4285@paulmck-ThinkPad-P17-Gen-1> <20220408174908.GK4285@paulmck-ThinkPad-P17-Gen-1> <20220408205440.GL4285@paulmck-ThinkPad-P17-Gen-1> In-Reply-To: <20220408205440.GL4285@paulmck-ThinkPad-P17-Gen-1> From: Joel Fernandes Date: Mon, 11 Apr 2022 11:17:02 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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 lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, On Fri, Apr 8, 2022 at 4:54 PM Paul E. McKenney wrote: [...] > > > > > > > > And is it really all -that- hard to specify an additional boot parameter > > > > > > > > across ChromeOS devices? Android seems to manage it. ;-) > > > > > > > > > > > > > > That's not the hard part I think. The hard part is to make sure a > > > > > > > future Linux user who is not an RCU expert does not forget to turn it > > > > > > > on. ChromeOS is not the only OS that I've seen someone forget to do it > > > > > > > ;-D. AFAIR, there were Android devices too in the past where I saw > > > > > > > this forgotten. I don't think we should rely on the users doing the > > > > > > > right thing (as much as possible). > > > > > > > > > > > > > > The single kernel binary point makes sense but in this case, I think > > > > > > > the bigger question that I'd have is what is the default behavior and > > > > > > > what do *most* users of RCU want. So we can keep sane defaults for the > > > > > > > majority and reduce human errors related to configuration. > > > > > > > > > > > > If both the ChromeOS and Android guys need it, I could reinstate the > > > > > > old RCU_NOCB_CPU_ALL Kconfig option. This was removed due to complaints > > > > > > about RCU Kconfig complexity, but I believe that Reviewed-by from ChromeOS > > > > > > and Android movers and shakers would overcome lingering objections. > > > > > > > > > > > > Would that help? > > > > > > > > > > Yes, I think I would love for such a change. I am planning to add a > > > > > test to ChromeOS to check whether config options were correctly set > > > > > up. So I can test for both the RCU_NOCB_CPU options. > > > > > > > > Very good! > > > > > > > > Do you love such a change enough to create the patch and to collect > > > > convincing Reviewed-by tags? > > > > > > Yes sure, just so I understand - basically I have to make the code in > > > my patch run when RCU_NOCB_CPU_ALL option is passed (and keep the > > > option default disabled), but otherwise default to the current > > > behavior, right? > > > > Sorry rephrasing, "make the code in my patch run when the new > > CONFIG_RCU_NOCB_CPU_ALL is enabled". > > Here is what I believe you are proposing: > > > --- rcu_nocbs rcu_nocbs=??? > > CONFIG_RCU_NOCB_CPU_ALL=n [1] [2] [3] > > CONFIG_RCU_NOCB_CPU_ALL=y [4] [4] [3] It is always a pleasure to read your well thought out emails ;-) > > [1] No CPUs are offloaded at boot. CPUs cannot be offloaded at > runtime. > > [2] No CPUs are offloaded at boot, but any CPU can be offloaded > (and later de-offloaded) at runtime. > > [3] The set of CPUs that are offloaded at boot are specified by the > mask, represented above with "???". The CPUs that are offloaded > at boot can be de-offloaded and offloaded at runtime. The CPUs > not offloaded at boot cannot be offloaded at runtime. Hmm, in other words you are saying that in current code, if only select CPUs are offloaded at boot - then only those can be toggled, but the others are deemed not offload-able? I am happy to leave that quirk/behavior alone as I don't care much right now (for our use cases) for runtime toggling. > [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). > 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. Thanks, - Joel