linux-kernel - Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 28 Jul 2006 08:25:41 -0700
From:	"Paul E. McKenney" <paulmck@...ibm.com>
To:	Esben Nielsen <nielsen.esben@...glemail.com>
Cc:	Bill Huey <billh@...ppy.monkey.org>, linux-kernel@...r.kernel.org,
	compudj@...stal.dyndns.org, rostedt@...dmis.org,
	tglx@...utronix.de, mingo@...e.hu, dipankar@...ibm.com,
	rusty@....ibm.com
Subject: Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU

On Fri, Jul 28, 2006 at 12:14:18PM +0100, Esben Nielsen wrote:
> On Thu, 27 Jul 2006, Paul E. McKenney wrote:
> >On Thu, Jul 27, 2006 at 05:48:57PM -0700, Bill Huey wrote:
> >>Another thing. What you mention above is really just having a set of 
> >>owners
> >>for the read side and not really a preemption list tracking thing with RCU
> >>and special scheduler path. The more RCU does this kind of thing the more
> >>it's just like a traditional read/write lock but with more parallelism 
> >>since
> >>it's holding on to read side owners on a per CPU basis.
> >
> >There are certainly some similarities between a priority-boosted RCU
> >read-side critical section and a priority-boosted read-side rwlock.
> >In theory, the crucial difference is that as long as one has sufficient
> >memory, one can delay priority-boosting the RCU read-side critical
> >sections without hurting update-side latency (aside from the grace period
> >delays, of course).

Here is a better list of the similarities and differences between
rwlock and RCU in -rt:

	Attribute			rwlock		RCU

	Readers block updates		Y		N

	Readers block freeing		Y		Y (synchronize_rcu())

	Updates block readers		Y		N

	Deterministic readers		N		Y

	Readers block readers		Y (-rt!)	N

	Readers preemptible		Y		Y

	Readers can block on locks	Y		Y

	Readers can block arbitrarily	Y		N (SRCU for this)


So in rwlock, priority boosting of readers is required to allow
updates to happen -at- -all-, while in RCU, priority boosting is
required to get deferred free (call_rcu(), synchronize_rcu()) unstuck.

> >So I will no doubt be regretting my long-standing advice to use
> >synchronize_rcu() over call_rcu().  Sooner or later someone will care
> >deeply about the grace-period latency.  In fact, I already got some
> >questions about that at this past OLS.  ;-)
> 
> Yick!! Do people really expect these things to finish in a predictable 
> amount of time?

Yeah, this is -almost- as unreasonable as expecting preemptible RCU
read-side critical sections!!!  ;-)  ;-)  ;-)

> This reminds me of C++ hackers starting to code Java. They want to use the 
> finalizer to close files etc. just as they use the destructor in C++, but 
> can't understand that they have to wait until the garbage collector has 
> run.
> RCU is a primitive kind of garbage collector. You should never depend on 
> how long it is about doing it's work, just that it will get done at some 
> point.

Seriously, it probably is not all that hard to get an upper bound on
synchronize_rcu() latency, as long as one is willing to put up with the
upper bound being a handful of jiffies (as opposed to being down in the
microsecond range.  In addition, this upper bound would be a function
of the number of tasks, and would also require boosting RCU read-side
priority to maximum.

That said, a (say) ten-jiffy upper bound on synchronize_rcu() would
probably not be what they were looking for.  ;-)

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/