Re: [PATCH RFC 3/9] RCU: Preemptible RCU

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Steven Rostedt <rostedt@...>
Cc: <linux-kernel@...>, <linux-rt-users@...>, <mingo@...>, <akpm@...>, <dipankar@...>, <josht@...>, <tytso@...>, <dvhltc@...>, <tglx@...>, <a.p.zijlstra@...>, <bunk@...>, <ego@...>, <oleg@...>
Date: Friday, September 21, 2007 - 8:26 pm

On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:

Covering the pieces that weren't in Peter's reply.  ;-)

And thank you -very- much for the careful and thorough review!!!


My fingers do this without any help from the rest of me, but I suppose
it is a bit of overkill in this case.


Good point, will add a comment.  You did get it right, "grace period".


Good point, perhaps a comment block above the enum giving a short
description of the purpose of each state.  Maybe more detail in
Documentation/RCU as well, as you suggest above.


I apologize for the repetition in this email.

I apologize for the repetition in this email.

I apologize for the repetition in this email.

Yep, will fix with either #define or static inline, as you suggested
in a later email.


Fair enough, as discussed earlier.


A later patch in the series fixes these -- I believe I got all of them.
(The priority-boost patch, IIRC.)


We beat this into the ground in other email.


wlli fxi!!!


;-)


s/no pending RCU calls/at least one pending RCU call/, but otherwise
spot on.

So if the RCU grace-period machinery is idle, the first CPU to take
a scheduling-clock interrupt after having posted an RCU callback will
get things going.


Yep.  The wait-for-acknowledgement cycle is there to handle rcu_read_lock() 
invocations on other CPUs that executed concurrently with the counter
increment in rcu_try_flip_idle().


Yep.  Note that rcu_read_lock() might well be able to use its local
.completed counter rather than the global one in rcu_ctrlblk, but
(1) it is not clear that the reduction in cache misses would outweigh
the per-CPU access overhead given that rcu_read_lock() happens a -lot-
more often than does a counter flip and (2) doing this could well require
cranking up GP_STAGES.


Yep!  More importantly, we know that no CPU will ever increment the
"old" set of counters.


Yep!


The only way it could cause a problem would be if there was ever
more than 4,294,967,296 outstanding rcu_read_lock() calls.  I believe
that lockdep screams if it sees more than 30 nested locks within a
single task, so for systems that support no more than 100M tasks, we
should be OK.  It might sometime be necessary to make this be a long
rather than an int.  Should we just do that now and be done with it?


Yep.  Because there are no memory barriers in rcu_read_unlock(), the
CPU is free to reorder the contents of the RCU read-side critical section
to follow the counter decrement.  This means that this CPU would still
be referencing RCU-protected data after it had told the world that it
was no longer doing so.  Forcing a memory barrier on each CPU guarantees
that if we see the memory-barrier acknowledge, we also see any prior
RCU read-side critical section.


Yep!


Other than noted above, yes.


Might be safe to ditch it, then.  I was afraid that there was a patch
out there somewhere still relying on it.


Glad you like it, and thank you again for the careful and thorough review.


I do greatly appreciate the compliments, especially coming from someone
like yourself, but it is also true that I have been implementing and
using RCU in various forms for longer than some Linux-community members
(not many, but a few) have been alive, and programming since 1972 or so.
Lots and lots of practice!

Hmmm...  I started programming about the same time that I started
jogging consistently.  Never realized that before.

I am thinking in terms of getting an improved discussion of RCU design and
use out there -- after all, the fifth anniversary of RCU's addition to
the kernel is coming right up.  This does deserve better documentation,
especially given that for several depressing weeks near the beginning
of 2005 I believed that a realtime-friendly RCU might not be possible.

						Thanx, Paul
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH RFC 0/9] RCU: Preemptible RCU, Paul E. McKenney, (Mon Sep 10, 2:30 pm)
Re: [PATCH RFC 0/9] RCU: Preemptible RCU, Ingo Molnar, (Mon Sep 10, 2:44 pm)
[PATCH RFC 6/9] RCU priority boosting for preemptible RCU, Paul E. McKenney, (Mon Sep 10, 2:39 pm)
Re: [PATCH RFC 6/9] RCU priority boosting for preemptible RCU, Paul E. McKenney, (Fri Oct 5, 10:07 am)
Re: [PATCH RFC 6/9] RCU priority boosting for preemptible RCU, Gautham R Shenoy, (Fri Sep 28, 6:56 pm)
Re: [PATCH RFC 6/9] RCU priority boosting for preemptible RCU, Paul E. McKenney, (Sat Sep 29, 11:11 pm)
[PATCH RFC 5/9] RCU: CPU hotplug support for preemptible RCU, Paul E. McKenney, (Mon Sep 10, 2:36 pm)
[PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Mon Sep 10, 2:34 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Oleg Nesterov, (Sun Sep 23, 1:38 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Sun Sep 23, 8:15 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Oleg Nesterov, (Wed Sep 26, 11:13 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Thu Sep 27, 11:46 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Oleg Nesterov, (Fri Sep 28, 10:47 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 28, 2:57 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Oleg Nesterov, (Sun Sep 30, 12:31 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Sun Sep 30, 9:20 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Davide Libenzi, (Sun Sep 30, 7:02 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Sun Sep 30, 9:37 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Oleg Nesterov, (Tue Oct 2, 2:02 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Davide Libenzi, (Mon Oct 1, 2:44 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Mon Oct 1, 3:21 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Davide Libenzi, (Mon Oct 1, 6:09 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Mon Oct 1, 6:24 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 11:20 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 7:03 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 8:32 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 9:19 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 9:43 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 10:56 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Sat Sep 22, 12:10 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 10:40 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 8:26 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 9:15 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 9:53 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 11:15 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Sat Sep 22, 12:07 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Peter Zijlstra, (Fri Sep 21, 11:46 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 6:31 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 6:44 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 7:23 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 7:44 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 6:06 pm)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Steven Rostedt, (Fri Sep 21, 12:17 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Dipankar Sarma, (Fri Sep 21, 1:56 am)
Re: [PATCH RFC 3/9] RCU: Preemptible RCU, Paul E. McKenney, (Fri Sep 21, 1:50 am)
[PATCH RFC 2/9] RCU: Fix barriers, Paul E. McKenney, (Mon Sep 10, 2:33 pm)