Messages in this thread | | | Date | Thu, 3 Nov 2011 06:34:35 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC tip/core/rcu 24/28] rcu: Introduce bulk reference count |
| |
On Wed, Nov 02, 2011 at 09:34:41PM -0700, Josh Triplett wrote: > On Wed, Nov 02, 2011 at 01:30:45PM -0700, Paul E. McKenney wrote: > > The RCU implementations, including SRCU, are designed to be used in a > > lock-like fashion, so that the read-side lock and unlock primitives must > > execute in the same context for any given read-side critical section. > > This constraint is enforced by lockdep-RCU. However, there is a need for > > something that acts more like a reference count than a lock, in order > > to allow (for example) the reference to be acquired within the context > > of an exception, while that same reference is released in the context of > > the task that encountered the exception. The cost of this capability is > > that the read-side operations incur the overhead of disabling interrupts. > > Some optimization is possible, and will be carried out if warranted. > > > > Note that although the current implementation allows a given reference to > > be acquired by one task and then released by another, all known possible > > implementations that allow this have scalability problems. Therefore, > > a given reference must be released by the same task that acquired it, > > though perhaps from an interrupt or exception handler running within > > that task's context. > > This new bulkref API seems in dire need of documentation. :) > > > --- a/include/linux/srcu.h > > +++ b/include/linux/srcu.h > > @@ -181,4 +181,54 @@ static inline void srcu_read_unlock(struct srcu_struct *sp, int idx) > > __srcu_read_unlock(sp, idx); > > } > > > > +/* Definitions for bulkref_t, currently defined in terms of SRCU. */ > > + > > +typedef struct srcu_struct bulkref_t; > > +int init_srcu_struct_fields(struct srcu_struct *sp); > > + > > +static inline int init_bulkref(bulkref_t *brp) > > +{ > > + return init_srcu_struct_fields(brp); > > +} > > Why can't this call init_srcu_struct and avoid the need to use the > previously unexported internal function?
Seems reasonable now that you mention it. ;-)
Thanx, Paul
| |