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;
Date:   Tue, 30 Aug 2022 18:22:44 +0200
From:   Frederic Weisbecker <frederic@kernel.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Rushikesh S Kadam <rushikesh.s.kadam@intel.com>,
        "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
        Neeraj upadhyay <neeraj.iitr10@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        rcu <rcu@vger.kernel.org>,
        Vineeth Pillai <vineeth@bitbyteword.org>
Subject: Re: [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous
 fixes
Message-ID: <20220830162244.GA73392@lothringen>
References: <20220819204857.3066329-1-joel@joelfernandes.org>
 <20220829134045.GA54589@lothringen>
 <1f7dd31b-f4d0-5c1c-ce28-c27f75c17f05@joelfernandes.org>
 <20220829194622.GA58291@lothringen>
 <CAEXW_YS593n8Gget+REaD-c8vT8Ht_AzOY0kXA_uc674LOyvVw@mail.gmail.com>
 <20220829204202.GQ6159@paulmck-ThinkPad-P17-Gen-1>
 <20220830105324.GA71266@lothringen>
 <20220830114343.GS6159@paulmck-ThinkPad-P17-Gen-1>
 <20220830160316.GC71266@lothringen>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220830160316.GC71266@lothringen>
Precedence: bulk

On Tue, Aug 30, 2022 at 06:03:16PM +0200, Frederic Weisbecker wrote:
> On Tue, Aug 30, 2022 at 04:43:43AM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 30, 2022 at 12:53:24PM +0200, Frederic Weisbecker wrote:
> > > On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote:
> > > > On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote:
> > > > > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote:
> > > > > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote:
> > > > > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote:
> > > > 
> > > > [ . .  . ]
> > > > 
> > > > > > > > 2) NOCB implies performance issues.
> > > > > > >
> > > > > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do
> > > > > > > with the extra scheduling overhead of the extra threads which is usually not a
> > > > > > > problem except that RCU is used in the critical path of boot up (on ChromeOS).
> > > > > >
> > > > > > I never measured it myself but executing callbacks on another CPUs, with
> > > > > > context switches and locking can only involve significant performance issues if callbacks
> > > > > > are frequent. So it's a tradeoff between power and performance.
> > > > > 
> > > > > In my testing of benchmarks on real systems with 8-16 CPUs, the
> > > > > performance hit is down in the noise. It is possible though that maybe
> > > > > one can write a non-realistic synthetic test to force the performance
> > > > > issues, but I've not seen it in the real world. Maybe on
> > > > > networking-heavy servers with lots of cores, you'll see it but their
> > > > > batteries if any would be pretty big :-).
> > > > 
> > > > To Frederic's point, if you have enough servers, even a 1% decrease in
> > > > power consumption is a very big deal.  ;-)
> > > 
> > > The world has enough servers, for that matters ;-)
> > 
> > True enough!  Now you need only demonstrate that call_rcu_lazy() for
> > !rcu_nocbs servers would actually deliver that 1%.  ;-)
> 
> Well, !rcu_nocbs is not only used by server but also by pretty much
> everything else, except android IIUC. I can't really measure the whole
> world but I don't see how the idleness of a server/router/desktop/embedded/rt/hpc
> device differs from the idleness of an android device.
> 
> But ok I'll try to measure that.

Although who knows, may be some periodic file operation while idle are specific
to Android. I'll try to trace lazy callbacks while idle and the number of grace
periods associated.