12 Dec, 2011

1 commit


16 Jan, 2010

1 commit

  • Add expedited functions. Review documentation and update
    obsolete verbiage. Also fix the advice for the RCU CPU-stall
    kernel configuration parameter, and document RCU CPU-stall
    warnings.

    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josh@joshtriplett.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    Cc: Valdis.Kletnieks@vt.edu
    Cc: dhowells@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

23 Aug, 2009

1 commit

  • Now that CONFIG_TREE_PREEMPT_RCU is in place, there is no
    further need for CONFIG_PREEMPT_RCU. Remove it, along with
    whatever subtle bugs it may (or may not) contain.

    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: akpm@linux-foundation.org
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josht@linux.vnet.ibm.com
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

02 Apr, 2009

1 commit


26 Jan, 2008

1 commit


04 Oct, 2006

1 commit

  • 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: Paul E. McKenney
    Signed-off-by: Josh Triplett
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

02 Feb, 2006

1 commit


11 Sep, 2005

1 commit


01 May, 2005

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds