Messages in this thread | | | Date | Fri, 30 Sep 2022 07:48:12 -0700 | From | "Paul E. McKenney" <> | 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
| |