From: Frederic Weisbecker <frederic@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Rushikesh S Kadam <rushikesh.s.kadam@intel.com>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
Neeraj upadhyay <neeraj.iitr10@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>, rcu <rcu@vger.kernel.org>,
Vineeth Pillai <vineeth@bitbyteword.org>
Subject: Re: [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous fixes
Date: Thu, 1 Sep 2022 20:28:04 +0200 [thread overview]
Message-ID: <20220901182804.GA108007@lothringen> (raw)
In-Reply-To: <20220901164928.GZ6159@paulmck-ThinkPad-P17-Gen-1>
On Thu, Sep 01, 2022 at 09:49:28AM -0700, Paul E. McKenney wrote:
> > On 9/1/2022 10:58 AM, Frederic Weisbecker wrote:
> > > On Thu, Sep 01, 2022 at 07:39:07AM -0700, Paul E. McKenney wrote:
> > >> On Wed, Aug 31, 2022 at 05:26:58PM +0200, Frederic Weisbecker wrote:
> > >>> On Tue, Aug 30, 2022 at 09:46:34AM -0700, Paul E. McKenney wrote:
> > >>>>> Although who knows, may be some periodic file operation while idle are specific
> > >>>>> to Android. I'll try to trace lazy callbacks while idle and the number of grace
> > >>>>> periods associated.
> > >>>>
> > >>>> Sounds like a good start.
> > >>>>
> > >>>> And yes, we don't need to show that the whole !NOCB world needs this,
> > >>>> just some significant portion of it. But we do need some decent evidence.
> > >>>> After all, it is all too easy to do a whole lot of work and find that
> > >>>> the expected benefits fail to materialize.
> > >>>
> > >>> So here is some quick test. I made a patch that replaces Joel's 1st patch
> > >>> with an implementation of call_rcu_lazy() that queues lazy callbacks
> > >>> through the regular call_rcu() way but it counts them in a lazy_count.
> > >>>
> > >>> Upon idle entry it reports whether the tick is retained solely by lazy
> > >>> callbacks or not.
> > >>>
> > >>> I get periodic and frequent results on my idle test box, something must be
> > >>> opening/closing some file periodically perhaps.
> > >>>
> > >>> Anyway the thing can be tested with this branch:
> > >>>
> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > >>> rcu/lazy-trace
> > >>>
> > >>> Excerpt:
> > >>>
> > >>> <idle>-0 [007] d..1. 414.226966: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
> > >>> <idle>-0 [007] d..1. 414.228271: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
> > >>> <idle>-0 [007] d..1. 414.232269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
> > >>> <idle>-0 [007] d..1. 414.236269: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
> > >>
> > >> Just to make sure that I understand, at this point, there is only the
> > >> one lazy callback (and no non-lazy callbacks) on this CPU, and that
> > >> CPU is therefore keeping the tick on only for the benefit of that one
> > >> lazy callback. And for the above four traces, this is likely the same
> > >> lazy callback.
> > >>
> > >> Did I get it right, or is there something else going on?
> > >
> > > Exactly that!
>
> Are these callbacks confined to the RCU_NEXT_READY_TAIL and RCU_NEXT_TAIL
> segments, which are the ones that could (in theory) buffer callbacks
> without having started a grace period? Or is it all the callbacks
> regardless of segment?
Ah good point!
So I just excluded when those segments have callbacks and I now only get
two tick retains every two seconds:
<idle>-0 [007] d..1. 1111.893649: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1111.967575: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1113.895470: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1115.669446: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1115.898144: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1117.202833: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1117.900521: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1119.903327: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1120.766864: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1121.909182: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1122.441927: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1123.908911: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1125.868505: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1125.910898: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1127.682837: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1127.913719: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1129.916740: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1130.967052: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1131.919256: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1132.957163: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [000] d..1. 1133.630082: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1133.923053: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1135.927054: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1136.067679: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1137.652294: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1137.932546: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1138.200768: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1139.932573: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1141.167489: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1141.935232: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1143.440538: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
<idle>-0 [007] d..1. 1143.938560: rcu_needs_cpu: BAD: 1 lazy callbacks retaining dynticks-idle
next prev parent reply other threads:[~2022-09-01 18:28 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 20:48 [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous fixes Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 01/14] rcu: Introduce call_rcu_lazy() API implementation Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 02/14] rcu: shrinker for lazy rcu Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 03/14] rcuscale: Add laziness and kfree tests Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 04/14] fs: Move call_rcu() to call_rcu_lazy() in some paths Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 05/14] rcutorture: Add test code for call_rcu_lazy() Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 06/14] debug: Toggle lazy at runtime and change flush jiffies Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 07/14] cred: Move call_rcu() to call_rcu_lazy() Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 08/14] security: " Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 09/14] net/core: " Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 10/14] kernel: Move various core kernel usages " Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 11/14] lib: Move call_rcu() " Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 12/14] i915: " Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 13/14] fork: Move thread_stack_free_rcu to call_rcu_lazy Joel Fernandes (Google)
2022-08-19 20:48 ` [PATCH v4 14/14] rcu/tree: Move trace_rcu_callback() before bypassing Joel Fernandes (Google)
2022-08-29 13:40 ` [PATCH v4 00/14] Implement call_rcu_lazy() and miscellaneous fixes Frederic Weisbecker
2022-08-29 16:45 ` Joel Fernandes
2022-08-29 19:46 ` Frederic Weisbecker
2022-08-29 20:31 ` Paul E. McKenney
2022-08-29 20:54 ` Joel Fernandes
2022-08-30 10:50 ` Frederic Weisbecker
2022-08-30 11:47 ` Paul E. McKenney
2022-08-29 20:36 ` Joel Fernandes
2022-08-29 20:42 ` Paul E. McKenney
2022-08-29 20:48 ` Joel Fernandes
2022-08-30 10:57 ` Frederic Weisbecker
2022-08-30 10:53 ` Frederic Weisbecker
2022-08-30 11:43 ` Paul E. McKenney
2022-08-30 16:03 ` Frederic Weisbecker
2022-08-30 16:22 ` Frederic Weisbecker
2022-08-30 16:44 ` Uladzislau Rezki
2022-08-30 18:53 ` Joel Fernandes
2022-09-01 11:29 ` Frederic Weisbecker
2022-09-01 11:59 ` Uladzislau Rezki
2022-09-01 14:41 ` Paul E. McKenney
2022-09-01 15:30 ` Frederic Weisbecker
2022-09-01 16:11 ` Joel Fernandes
2022-09-01 16:52 ` Paul E. McKenney
2022-09-01 15:13 ` Frederic Weisbecker
2022-09-01 16:07 ` Joel Fernandes
2022-08-30 16:46 ` Paul E. McKenney
2022-08-31 15:26 ` Frederic Weisbecker
2022-09-01 14:39 ` Paul E. McKenney
2022-09-01 14:58 ` Frederic Weisbecker
2022-09-01 16:07 ` Joel Fernandes
2022-09-01 16:49 ` Paul E. McKenney
2022-09-01 18:28 ` Frederic Weisbecker [this message]
2022-09-01 20:36 ` Paul E. McKenney
2022-08-30 18:46 ` Joel Fernandes
2022-08-30 10:26 ` Frederic Weisbecker
2022-08-30 18:40 ` Joel Fernandes
2022-08-29 19:57 ` Paul E. McKenney
2022-08-30 10:43 ` Frederic Weisbecker
2022-08-30 12:08 ` Paul E. McKenney
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=20220901182804.GA108007@lothringen \
--to=frederic@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=rushikesh.s.kadam@intel.com \
--cc=urezki@gmail.com \
--cc=vineeth@bitbyteword.org \
/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.