[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220929195641.GZ4196@paulmck-ThinkPad-P17-Gen-1>
Date: Thu, 29 Sep 2022 12:56:41 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, Boqun Feng <boqun.feng@...il.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: RCU vs NOHZ
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.
Thanx, Paul
Powered by blists - more mailing lists