linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joe Korty <joe.korty@ccur.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"loic.minier@linaro.org" <loic.minier@linaro.org>,
	"dhaval.giani@gmail.com" <dhaval.giani@gmail.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"josh@joshtriplett.org" <josh@joshtriplett.org>,
	"houston.jim@comcast.net" <houston.jim@comcast.net>,
	"corbet@lwn.net" <corbet@lwn.net>
Subject: Re: JRCU Theory of Operation
Date: Sun, 13 Mar 2011 19:53:51 -0400	[thread overview]
Message-ID: <20110313235351.GA15931@tsunami.ccur.com> (raw)
In-Reply-To: <20110313055627.GW2234@linux.vnet.ibm.com>

On Sun, Mar 13, 2011 at 12:56:27AM -0500, Paul E. McKenney wrote:
> > Even though I keep saying 50msecs for everything, I
> > suspect that the Q switching meets all the above quiescent
> > requirements in a few tens of microseconds.  Thus even
> > a 1 msec JRCU sampling period is expected to be safe,
> > at least in regard to Q switching.
> 
> I would feel better about this is the CPU vendors were willing to give
> an upper bound...

I suspect they don't because they don't really know
themselves .. in that whatever it is, it keeps changing
from chip to chip, trying to describe such would be beyond
the english language, and any description would tie them
down on what they could do in future chip designs.

But, there is a hint in current behavior.  It is well known
that many multithreaded apps don't uses barriers at all;
the authors had no idea what they are for.  Yet such apps
largely work.  This implies that the chip designers are
very aggressive in doing implied memory barriers wherever
possible, and they are very aggressive in pushing out
stores to caches very quickly even when memory barriers,
implied or not, are not present.

Joe

  reply	other threads:[~2011-03-13 23:54 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-04 23:21 dyntick-hpc and RCU Paul E. McKenney
2010-11-05  5:27 ` Frederic Weisbecker
2010-11-05  5:38   ` Frederic Weisbecker
2010-11-05 15:06     ` Paul E. McKenney
2010-11-05 20:06       ` Dhaval Giani
2010-11-05 15:04   ` Paul E. McKenney
2010-11-08 14:10     ` Frederic Weisbecker
2010-11-05 21:00 ` [PATCH] a local-timer-free version of RCU Joe Korty
2010-11-06 19:28   ` Paul E. McKenney
2010-11-06 19:34     ` Mathieu Desnoyers
2010-11-06 19:42       ` Mathieu Desnoyers
2010-11-06 19:44         ` Paul E. McKenney
2010-11-08  2:11     ` Udo A. Steinberg
2010-11-08  2:19       ` Udo A. Steinberg
2010-11-08  2:54         ` Paul E. McKenney
2010-11-08 15:32           ` Frederic Weisbecker
2010-11-08 19:38             ` Paul E. McKenney
2010-11-08 20:40               ` Frederic Weisbecker
2010-11-10 18:08                 ` Paul E. McKenney
2010-11-08 15:06     ` Frederic Weisbecker
2010-11-08 15:18       ` Joe Korty
2010-11-08 19:50         ` Paul E. McKenney
2010-11-08 19:49       ` Paul E. McKenney
2010-11-08 20:51         ` Frederic Weisbecker
2010-11-06 20:03   ` Mathieu Desnoyers
2010-11-09  9:22   ` Lai Jiangshan
2010-11-10 15:54     ` Frederic Weisbecker
2010-11-10 17:31       ` Peter Zijlstra
2010-11-10 17:45         ` Frederic Weisbecker
2010-11-11  4:19         ` Paul E. McKenney
2010-11-13 22:30           ` Frederic Weisbecker
2010-11-16  1:28             ` Paul E. McKenney
2010-11-16 13:52               ` Frederic Weisbecker
2010-11-16 15:51                 ` Paul E. McKenney
2010-11-17  0:52                   ` Frederic Weisbecker
2010-11-17  1:25                     ` Paul E. McKenney
2011-03-07 20:31                     ` [PATCH] An RCU for SMP with a single CPU garbage collector Joe Korty
     [not found]                       ` <20110307210157.GG3104@linux.vnet.ibm.com>
2011-03-07 21:16                         ` Joe Korty
2011-03-07 21:33                           ` Joe Korty
2011-03-07 22:51                           ` Joe Korty
2011-03-08  9:07                             ` Paul E. McKenney
2011-03-08 15:57                               ` Joe Korty
2011-03-08 22:53                                 ` Joe Korty
2011-03-10  0:30                                   ` Paul E. McKenney
2011-03-10  0:28                                 ` Paul E. McKenney
2011-03-09 22:29                           ` Frederic Weisbecker
2011-03-09 22:15                       ` [PATCH 2/4] jrcu: tap rcu_read_unlock Joe Korty
2011-03-10  0:34                         ` Paul E. McKenney
2011-03-10 19:50                           ` JRCU Theory of Operation Joe Korty
2011-03-12 14:36                             ` Paul E. McKenney
2011-03-13  0:43                               ` Joe Korty
2011-03-13  5:56                                 ` Paul E. McKenney
2011-03-13 23:53                                   ` Joe Korty [this message]
2011-03-14  0:50                                     ` Paul E. McKenney
2011-03-14  0:55                                       ` Josh Triplett
2011-03-09 22:16                       ` [PATCH 3/4] jrcu: tap might_resched() Joe Korty
2011-03-09 22:17                       ` [PATCH 4/4] jrcu: add new stat to /sys/kernel/debug/rcu/rcudata Joe Korty
2011-03-09 22:19                       ` [PATCH 1/4] jrcu: remove preempt_enable() tap [resend] Joe Korty
2011-03-12 14:36                       ` [PATCH] An RCU for SMP with a single CPU garbage collector Paul E. McKenney
2011-03-13  1:25                         ` Joe Korty
2011-03-13  6:09                           ` 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=20110313235351.GA15931@tsunami.ccur.com \
    --to=joe.korty@ccur.com \
    --cc=corbet@lwn.net \
    --cc=dhaval.giani@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=houston.jim@comcast.net \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.minier@linaro.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).