1. 26 10月, 2009 1 次提交
  2. 04 10月, 2006 3 次提交
    • A
      [PATCH] SRCU: report out-of-memory errors · e6a92013
      Alan Stern 提交于
      Currently the init_srcu_struct() routine has no way to report out-of-memory
      errors.  This patch (as761) makes it return -ENOMEM when the per-cpu data
      allocation fails.
      
      The patch also makes srcu_init_notifier_head() report a BUG if a notifier
      head can't be initialized.  Perhaps it should return -ENOMEM instead, but
      in the most likely cases where this might occur I don't think any recovery
      is possible.  Notifier chains generally are not created dynamically.
      
      [akpm@osdl.org: avoid statement-with-side-effect in macro]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e6a92013
    • A
      [PATCH] Add SRCU-based notifier chains · eabc0694
      Alan Stern 提交于
      This patch (as751) adds a new type of notifier chain, based on the SRCU
      (Sleepable Read-Copy Update) primitives recently added to the kernel.  An
      SRCU notifier chain is much like a blocking notifier chain, in that it must
      be called in process context and its callout routines are allowed to sleep.
       The difference is that the chain's links are protected by the SRCU
      mechanism rather than by an rw-semaphore, so calling the chain has
      extremely low overhead: no memory barriers and no cache-line bouncing.  On
      the other hand, unregistering from the chain is expensive and the chain
      head requires special runtime initialization (plus cleanup if it is to be
      deallocated).
      
      SRCU notifiers are appropriate for notifiers that will be called very
      frequently and for which unregistration occurs very seldom.  The proposed
      "task notifier" scheme qualifies, as may some of the network notifiers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Acked-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      eabc0694
    • P
      [PATCH] srcu-3: RCU variant permitting read-side blocking · 621934ee
      Paul E. McKenney 提交于
      Updated patch adding a variant of RCU that permits sleeping in read-side
      critical sections.  SRCU is as follows:
      
      o	Each use of SRCU creates its own srcu_struct, and each
      	srcu_struct has its own set of grace periods.  This is
      	critical, as it prevents one subsystem with a blocking
      	reader from holding up SRCU grace periods for other
      	subsystems.
      
      o	The SRCU primitives (srcu_read_lock(), srcu_read_unlock(),
      	and synchronize_srcu()) all take a pointer to a srcu_struct.
      
      o	The SRCU primitives must be called from process context.
      
      o	srcu_read_lock() returns an int that must be passed to
      	the matching srcu_read_unlock().  Realtime RCU avoids the
      	need for this by storing the state in the task struct,
      	but SRCU needs to allow a given code path to pass through
      	multiple SRCU domains -- storing state in the task struct
      	would therefore require either arbitrary space in the
      	task struct or arbitrary limits on SRCU nesting.  So I
      	kicked the state-storage problem up to the caller.
      
      	Of course, it is not permitted to call synchronize_srcu()
      	while in an SRCU read-side critical section.
      
      o	There is no call_srcu().  It would not be hard to implement
      	one, but it seems like too easy a way to OOM the system.
      	(Hey, we have enough trouble with call_rcu(), which does
      	-not- permit readers to sleep!!!)  So, if you want it,
      	please tell me why...
      
      [josht@us.ibm.com: sparse notation]
      Signed-off-by: NPaul E. McKenney <paulmck@us.ibm.com>
      Signed-off-by: NJosh Triplett <josh@freedesktop.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      621934ee