All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: RCU vs NOHZ
Date: Fri, 16 Sep 2022 14:11:10 -0400	[thread overview]
Message-ID: <CAEXW_YTN7mnQSN2eJCysLsZOq+8JEOV6pvgw3LDTT=0mnkC2SA@mail.gmail.com> (raw)
In-Reply-To: <YyQ/zn54D1uoaIc1@hirez.programming.kicks-ass.net>

Hi Peter,

On Fri, Sep 16, 2022 at 5:20 AM Peter Zijlstra <peterz@infradead.org> wrote:
[...]
> > It wasn't enabled for ChromeOS.
> >
> > When fully enabled, it gave them the energy-efficiency advantages Joel
> > described.  And then Joel described some additional call_rcu_lazy()
> > changes that provided even better energy efficiency.  Though I believe
> > that the application should also be changed to avoid incessantly opening
> > and closing that file while the device is idle, as this would remove
> > -all- RCU work when nearly idle.  But some of the other call_rcu_lazy()
> > use cases would likely remain.
>
> So I'm thinking the scheme I outlined gets you most if not all of what
> lazy would get you without having to add the lazy thing. A CPU is never
> refused deep idle when it passes off the callbacks.
>
> The NOHZ thing is a nice hook for 'this-cpu-wants-to-go-idle-long-term'
> and do our utmost bestest to move work away from it. You *want* to break
> affinity at this point.
>
> If you hate on the global, push it to a per rcu_node offload list until
> the whole node is idle and then push it up the next rcu_node level until
> you reach the top.
>
> Then when the top rcu_node is full idle; you can insta progress the QS
> state and run the callbacks and go idle.

In my opinion the speed brakes have to be applied before the GP and
other threads are even awakened. The issue Android and ChromeOS
observe is that even a single CB queued every few jiffies can cause
work that can be otherwise delayed / batched, to be scheduled in. I am
not sure if your suggestions above address that. Does it?

Try this experiment on your ADL system (for fun). Boot to the login
screen on any distro, and before logging in, run turbostat over ssh
and observe PC8 percent residencies. Now increase
jiffies_till_first_fqs boot parameter value to 64 or so and try again.
You may be surprised how much PC8 percent increases by delaying RCU
and batching callbacks (via jiffies boot option) Admittedly this is
more amplified on ADL because of package-C-states, firmware and what
not, and isn’t as much a problem on Android; but still gives a nice
power improvement there.

thanks,

 - Joel

  reply	other threads:[~2022-09-16 18:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-15  8:39 RCU vs NOHZ Peter Zijlstra
2022-09-15 15:37 ` Joel Fernandes
2022-09-15 16:06 ` Paul E. McKenney
2022-09-15 18:50   ` Peter Zijlstra
2022-09-15 19:14     ` Paul E. McKenney
2022-09-15 22:30       ` Peter Zijlstra
2022-09-16  3:40         ` Joel Fernandes
2022-09-16  7:58         ` Paul E. McKenney
2022-09-16  9:20           ` Peter Zijlstra
2022-09-16 18:11             ` Joel Fernandes [this message]
2022-09-17 13:35               ` Peter Zijlstra
2022-09-17 13:52                 ` Joel Fernandes
2022-09-17 14:28                   ` Paul E. McKenney
2022-09-17 14:25             ` Paul E. McKenney
2022-09-21 21:36               ` Paul E. McKenney
2022-09-23 15:12                 ` Joel Fernandes
2022-09-23 16:01                   ` Paul E. McKenney
2022-09-23 17:47                     ` Joel Fernandes
2022-09-23 18:15                       ` Paul E. McKenney
2022-09-29 11:06                 ` Peter Zijlstra
2022-09-29 10:55               ` Peter Zijlstra
2022-09-29 15:20                 ` Paul E. McKenney
2022-09-29 15:46                   ` Paul E. McKenney
2022-09-29 16:05                     ` Joel Fernandes
2022-09-29 16:23                     ` Peter Zijlstra
2022-09-29 16:42                       ` Paul E. McKenney
2022-09-29 19:01                         ` Peter Zijlstra
2022-09-29 19:52                           ` Paul E. McKenney
2022-09-29 16:18                   ` Peter Zijlstra
2022-09-29 16:36                     ` Paul E. McKenney
2022-09-29 19:08                       ` Peter Zijlstra
2022-09-29 19:56                         ` Paul E. McKenney
2022-09-30 14:48                           ` Paul E. McKenney
2022-09-23 19:47 Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEXW_YTN7mnQSN2eJCysLsZOq+8JEOV6pvgw3LDTT=0mnkC2SA@mail.gmail.com' \
    --to=joel@joelfernandes.org \
    --cc=boqun.feng@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.