1. 19 5月, 2008 1 次提交
  2. 17 7月, 2007 1 次提交
  3. 04 10月, 2006 1 次提交
    • 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
  4. 26 6月, 2006 1 次提交
  5. 02 2月, 2006 1 次提交
  6. 11 9月, 2005 1 次提交
  7. 01 5月, 2005 1 次提交
  8. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4