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:   Fri, 30 Sep 2022 07:48:12 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org, Boqun Feng <boqun.feng@gmail.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: RCU vs NOHZ
Message-ID: <20220930144812.GA1801669@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <YyOnilnwnLKA9ghN@hirez.programming.kicks-ass.net>
 <20220916075817.GE246308@paulmck-ThinkPad-P17-Gen-1>
 <YyQ/zn54D1uoaIc1@hirez.programming.kicks-ass.net>
 <20220917142508.GF246308@paulmck-ThinkPad-P17-Gen-1>
 <YzV5vqoLInptafJm@hirez.programming.kicks-ass.net>
 <20220929152044.GE4196@paulmck-ThinkPad-P17-Gen-1>
 <YzXFWEL52MRp2s5j@hirez.programming.kicks-ass.net>
 <20220929163624.GN4196@paulmck-ThinkPad-P17-Gen-1>
 <YzXtOi7rjjWI0ea0@hirez.programming.kicks-ass.net>
 <20220929195641.GZ4196@paulmck-ThinkPad-P17-Gen-1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220929195641.GZ4196@paulmck-ThinkPad-P17-Gen-1>
Precedence: bulk

On Thu, Sep 29, 2022 at 12:56:41PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2022 at 09:08:42PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2022 at 09:36:24AM -0700, Paul E. McKenney wrote:
> > 
> > > > How has this been tried; and why did the energy cost go up? Is this
> > > > because the offload thread ends up waking up the CPU we just put to
> > > > sleep?
> > > 
> > > Because doing the additional work consumes energy.  I am not clear on
> > > exactly what you are asking for here, given the limitations of the tools
> > > that measure energy consumption.
> > 
> > What additional work? Splicing the cpu pending list onto another list
> > with or without atomic op barely qualifies for work. The main point is
> > making sure the pending list isn't in the way of going (deep) idle.
> 
> Very good.  Send a patch.
> 
> After some time, its successor might correctly handle lock/memory
> contention, CPU hotplug, presumed upcoming runtime changes in CPUs'
> housekeeping status, frequent idle entry/exit, grace period begin/end,
> quiet embedded systems, and so on.
> 
> Then we can see if it actually reduces power consumption.

Another approach is to runtime-offload CPUs that have been mostly idle,
and switch back to deoffloaded during busy periods.

							Thanx, Paul