On Fri, Apr 16, 2010 at 09:37:02PM +0200, Peter Zijlstra wrote:
quoted text
> On Fri, 2010-04-16 at 09:45 -0700, Paul E. McKenney wrote:
> > o       mutex_lock(): Critical sections need not guarantee
> >         forward progress, as general blocking is permitted.
> > 
> Right, I would argue that they should guarantee fwd progress, but due to
> being able to schedule while holding them, its harder to enforce.
> 
> Anything that is waiting for uncertainty should do so without any locks
> held and simply re-acquire them once such an event does occur.

Agreed.  But holding a small-scope mutex for (say) 60 seconds would not be
a problem (at 120 seconds, you might start seeing softlockup messages).
In contrast, holding off an RCU grace period for 60 seconds might well
OOM the machine, especially a small embedded system with limited memory.

quoted text
> > So the easy response is "just use SRCU."  Of course, SRCU has some
> > disadvantages at the moment:
> > 
> > o       The return value from srcu_read_lock() must be passed to
> >         srcu_read_unlock().  I believe that I can fix this.
> > 
> > o       There is no call_srcu().  I believe that I can fix this.
> > 
> > o       SRCU uses a flat per-CPU counter scheme that is not particularly
> >         scalable.  I believe that I can fix this.
> > 
> > o       SRCU's current implementation makes it almost impossible to
> >         implement priority boosting.  I believe that I can fix this.
> > 
> > o       SRCU requires explicit initialization of the underlying
> >         srcu_struct.  Unfortunately, I don't see a reasonable way
> >         around this.  Not yet, anyway.
> > 
> > So, is there anything else that you don't like about SRCU?
> 
> No, I quite like SRCU when implemented as preemptible tree RCU, and I
> don't at all mind that last point, all dynamic things need some sort of
> init. All locks certainly have.

Very good!!!  I should clarify, though -- by "explicit initialization",
I mean that there needs to be a run-time call to init_srcu_struct().
Unless there is some clever way to initialize an array of pointers to
per-CPU structures at compile time.  And, conversely, a way to initialize
pointers in a per-CPU structure to point to possibly-different rcu_node
structures.

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