Re: [RFC, PATCH] state machine based rcu

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Paul E. McKenney
Date: Friday, August 22, 2008 - 12:02 pm

On Thu, Aug 21, 2008 at 05:27:37PM +0200, Manfred Spraul wrote:

Interesting approach!!!  Some questions and comments interspersed.

							Thanx, Paul


Good approach!  Will steal it.  ;-)


Interesting approach!  My main concern would be that this might extend
grace periods (which has come up with preemptable RCU).  Or do you
have some clever way of overlapping the required processing for the
various states?


How do you handle the uncertainty as to when a given state begins?
Here is an example sequence of events that I would be worried about:

o	CPU 0 notices the end of a grace period, so updates the state.

o	CPU 1 notices the new grace period while in a quiescent state.
	It checks into the RCU state machine.

o	CPU 1 starts a long-running RCU read-side critical section.

o	CPU 2 deletes one of the elements that CPU 1 is referencing,
	and registers an RCU callback to free it after a grace period.

o	CPU 2 notices that a new grace period has commenced.

o	The remaining CPUs (other than CPU 1, which already passed
	through a quiescent state) pass through a quiescent state, ending
	the grace period.  CPU 1 remains in its RCU read-side critical
	section.

o	The RCU grace period ends, permitting CPU 2 to free the element
	that it removed -- but which CPU 1 is still referencing.

This scenario used to be handled by an arcane and confusing combination of
flags and queues.  Jiangshan recently unified this into another stage of
queuing, which seems to work very well -- and much more straightforwardly.

It is possible that your state machine handles this, but if so, it was not
obvious to me.


The approach preemptable RCU uses to interact with dynticks should
handle this.  You mentioned using atomic operations previously, which
might simplify the code (Steve and I were concerned that use of atomic
ops in the interrupt path would get an automatic NACK, but it is quite
possible that we were being too paranoid).


People are apparently looking at 4096 CPUs these days, FWIW.  I don't
see any architectural limit in your code, so just FYI.


This could be made to work, but the advantage of preemptable RCU's
upcounter approach is the ability to count momentarily dropping into
dyntick idle mode as a quiescent state -- even if we don't happen to
look at that CPU while it is actually residing in dyntick idle mode.

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC, PATCH] state machine based rcu, Manfred Spraul, (Thu Aug 21, 8:27 am)
Re: [RFC, PATCH] state machine based rcu, Manfred Spraul, (Thu Aug 21, 8:29 am)
Re: [RFC, PATCH] state machine based rcu, Manfred Spraul, (Thu Aug 21, 8:32 am)
Re: [RFC, PATCH] state machine based rcu, Paul E. McKenney, (Fri Aug 22, 12:02 pm)
Re: [RFC, PATCH] state machine based rcu, Manfred Spraul, (Sat Aug 23, 1:16 am)
Re: [RFC, PATCH] state machine based rcu, Paul E. McKenney, (Sun Aug 24, 10:09 am)
Re: [RFC, PATCH] state machine based rcu, Paul E. McKenney, (Tue Aug 26, 9:08 am)
Re: [RFC, PATCH] state machine based rcu, Manfred Spraul, (Tue Aug 26, 10:19 am)
Re: [RFC, PATCH] state machine based rcu, Paul E. McKenney, (Tue Aug 26, 11:13 am)
Re: [RFC, PATCH] state machine based rcu, Randy Dunlap, (Tue Sep 30, 5:02 pm)