From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Christoph Lameter <cl@linux.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops
Date: Tue, 2 Sep 2014 19:11:52 -0700 [thread overview]
Message-ID: <20140903021152.GA14069@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1409021819500.5437@gentwo.org>
On Tue, Sep 02, 2014 at 06:22:52PM -0500, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Paul E. McKenney wrote:
>
> > Yep, these two have been on my "when I am feeling insanely gutsy" list
> > for quite some time.
> >
> > But I have to ask... On x86, is a pair of mfence instructions really
> > cheaper than an atomic increment?
>
> Not sure why you would need an mfence instruction?
Because otherwise RCU can break. As soon as the grace-period machinery
sees that the value of this variable is even, it assumes a quiescent
state. If there are no memory barriers, the non-quiescent code might
not have completed executing, and your kernel's actuarial statistics
become sub-optimal.
Thanx, Paul
> > > If the first patch I send gets merged then a lot of other this_cpu related
> > > optimizations become possible regardless of the ones in the RFC.
> >
> > Yep, I am queuing that one.
>
> Great.
>
> > But could you please do future patches against the rcu/dev branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git?
> > I had to hand-apply due to conflicts. Please see below for my version,
> > and please check to make sure that I didn't mess something up in the
> > translation.
>
> Looks ok. Will use the correct tree next time.
>
>
next prev parent reply other threads:[~2014-09-03 2:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 20:14 [RFC] dynticks: dynticks_idle is only modified locally use this_cpu ops Christoph Lameter
2014-09-02 20:37 ` Paul E. McKenney
2014-09-02 20:47 ` Christoph Lameter
2014-09-02 21:15 ` Paul E. McKenney
2014-09-02 23:22 ` Christoph Lameter
2014-09-03 2:11 ` Paul E. McKenney [this message]
2014-09-03 14:10 ` Christoph Lameter
2014-09-03 14:43 ` Paul E. McKenney
2014-09-03 15:51 ` Christoph Lameter
2014-09-03 17:14 ` Paul E. McKenney
2014-09-03 17:43 ` Christoph Lameter
2014-09-03 18:19 ` Paul E. McKenney
2014-09-04 15:04 ` Christoph Lameter
2014-09-04 16:16 ` Paul E. McKenney
2014-09-04 18:19 ` Christoph Lameter
2014-09-04 19:32 ` Paul E. McKenney
2014-09-08 18:20 ` Christoph Lameter
2014-09-10 22:18 ` 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=20140903021152.GA14069@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=cl@linux.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.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.