linux-kernel - Re: RCU vs NOHZ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20220930144812.GA1801669@paulmck-ThinkPad-P17-Gen-1>
Date:   Fri, 30 Sep 2022 07:48:12 -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 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