public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Tue, 30 Aug 2022 12:53:24 +0200	[thread overview]
Message-ID: <20220830105324.GA71266@lothringen> (raw)
In-Reply-To: <20220829204202.GQ6159@paulmck-ThinkPad-P17-Gen-1>

On Mon, Aug 29, 2022 at 01:42:02PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 29, 2022 at 04:36:40PM -0400, Joel Fernandes wrote:
> > On Mon, Aug 29, 2022 at 3:46 PM Frederic Weisbecker <frederic@kernel.org> wrote:
> > > On Mon, Aug 29, 2022 at 12:45:40PM -0400, Joel Fernandes wrote:
> > > > On 8/29/2022 9:40 AM, Frederic Weisbecker wrote:
> 
> [ . .  . ]
> 
> > > > > 2) NOCB implies performance issues.
> > > >
> > > > Which kinds of? There is slightly worse boot times, but I'm guessing that's do
> > > > with the extra scheduling overhead of the extra threads which is usually not a
> > > > problem except that RCU is used in the critical path of boot up (on ChromeOS).
> > >
> > > I never measured it myself but executing callbacks on another CPUs, with
> > > context switches and locking can only involve significant performance issues if callbacks
> > > are frequent. So it's a tradeoff between power and performance.
> > 
> > In my testing of benchmarks on real systems with 8-16 CPUs, the
> > performance hit is down in the noise. It is possible though that maybe
> > one can write a non-realistic synthetic test to force the performance
> > issues, but I've not seen it in the real world. Maybe on
> > networking-heavy servers with lots of cores, you'll see it but their
> > batteries if any would be pretty big :-).
> 
> To Frederic's point, if you have enough servers, even a 1% decrease in
> power consumption is a very big deal.  ;-)

The world has enough servers, for that matters ;-)

  parent reply	other threads:[~2022-08-30 10:53 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 [this message]
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
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=20220830105324.GA71266@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox