26 Jun, 2008

1 commit

  • This patch allows torturing RCU from irq handlers (timers, in this case).
    A new module parameter irqreader enables such additional torturing,
    and is enabled by default. Variants of RCU that do not tolerate readers
    being called from irq handlers (e.g., SRCU) ignore irqreader.

    Signed-off-by: Paul E. McKenney
    Cc: josh@freedesktop.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: dino@in.ibm.com
    Cc: akpm@linux-foundation.org
    Cc: torvalds@linux-foundation.org
    Cc: vegard.nossum@gmail.com
    Cc: adobriyan@gmail.com
    Cc: oleg@tv-sign.ru
    Cc: bunk@kernel.org
    Cc: rjw@sisk.pl
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

19 Jun, 2008

1 commit

  • This patch re-institutes the ability to build rcutorture directly into
    the Linux kernel. The reason that this capability was removed was that
    this could result in your kernel being pretty much useless, as rcutorture
    would be running starting from early boot. This problem has been avoided
    by (1) making rcutorture run only three seconds of every six by default,
    (2) adding a CONFIG_RCU_TORTURE_TEST_RUNNABLE that permits rcutorture
    to be quiesced at boot time, and (3) adding a sysctl in /proc named
    /proc/sys/kernel/rcutorture_runnable that permits rcutorture to be
    quiesced and unquiesced when built into the kernel.

    Please note that this /proc file is -not- available when rcutorture
    is built as a module. Please also note that to get the earlier
    take-no-prisoners behavior, you must use the boot command line to set
    rcutorture's "stutter" parameter to zero.

    The rcutorture quiescing mechanism is currently quite crude: loops
    in each rcutorture process that poll a global variable once per tick.
    Suggestions for improvement are welcome. The default action will
    be to reduce the polling rate to a few times per second.

    Signed-off-by: Paul E. McKenney
    Suggested-by: Ingo Molnar
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

18 Jun, 2008

1 commit

  • This patch takes a step towards making rcutorture more brutal by allowing
    the test to be automatically periodically paused, with the default being
    to run the test for five seconds then pause for five seconds and repeat.
    This behavior can be controlled using a new "stutter" module parameter, so
    that "stutter=0" gives the old default behavior of running continuously.

    Starting and stopping rcutorture more heavily stresses RCU's interaction
    with the scheduler, as well as exercising more paths through the
    grace-period detection code.

    Note that the default to "shuffle_interval" has also been adjusted from
    5 seconds to 3 seconds to provide varying overlap with the "stutter"
    interval.

    I am still unable to provoke the failures that Alexey has been seeing,
    even with this patch, but will be doing a few additional things to beef
    up rcutorture.

    Suggested-by: Ingo Molnar
    Signed-off-by: Paul E. McKenney
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

19 May, 2008

1 commit


14 Feb, 2008

1 commit


26 Jan, 2008

1 commit


17 Oct, 2007

1 commit


17 Jul, 2007

1 commit


04 Oct, 2006

8 commits

  • Implement torture testing for the "sched" variant of RCU, which uses
    preempt_disable, preempt_enable, and synchronize_sched.

    Signed-off-by: Josh Triplett
    Acked-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     
  • Use the newly-generic synchronous deferred free function to implement torture
    testing for rcu_bh using synchronize_rcu_bh rather than the asynchronous
    call_rcu_bh.

    Signed-off-by: Josh Triplett
    Acked-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     
  • Use the newly-generic synchronous deferred free function to implement torture
    testing for RCU using synchronize_rcu rather than the asynchronous call_rcu.

    Signed-off-by: Josh Triplett
    Acked-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     
  • rcutorture currently has one writer and an arbitrary number of readers. To
    better exercise some of the code paths in RCU implementations, add fake
    writer threads which call the synchronize function for the RCU variant in a
    loop, with a delay between calls to arrange for different numbers of
    writers running in parallel.

    [bunk@stusta.de: cleanup]
    Acked-by: Paul McKenney
    Cc: Dipkanar Sarma
    Signed-off-by: Josh Triplett
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Josh Triplett
     
  • Adds SRCU operations to rcutorture and updates rcutorture documentation.
    Also increases the stress imposed by the rcutorture test.

    [bunk@stusta.de: make needlessly global code static]
    Signed-off-by: Paul E. McKenney
    Cc: Paul E. McKenney
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

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

    Paul E. McKenney
     
  • Remove many duplicated words under Documentation/ and do other small
    cleanups.

    Examples:
    "and and" --> "and"
    "in in" --> "in"
    "the the" --> "the"
    "the the" --> "to the"
    ...

    Signed-off-by: Paolo Ornati
    Signed-off-by: Adrian Bunk

    Paolo Ornati
     
  • This patch fixes typos in various Documentation txts. The patch addresses
    some words starting with the letter 'S'.

    Signed-off-by: Matt LaPlante
    Acked-by: Alan Cox
    Acked-by: Randy Dunlap
    Signed-off-by: Adrian Bunk

    Matt LaPlante
     

11 Jul, 2006

1 commit


28 Jun, 2006

2 commits


26 Jun, 2006

1 commit

  • An update to the RCU documentation calling out the
    self-limiting-update-rate advantages of synchronize_rcu(), and describing
    how to use call_rcu() in a way that results in self-limiting updates.
    Self-limiting updates are important to avoiding RCU-induced OOM in face of
    denial-of-service attacks.

    Signed-off-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

23 Jun, 2006

1 commit


29 Mar, 2006

1 commit


25 Mar, 2006

1 commit


02 Feb, 2006

1 commit


09 Jan, 2006

1 commit


07 Nov, 2005

1 commit


31 Oct, 2005

1 commit

  • This patch is a rewrite of the one submitted on October 1st, using modules
    (http://marc.theaimsgroup.com/?l=linux-kernel&m=112819093522998&w=2).

    This rewrite adds a tristate CONFIG_RCU_TORTURE_TEST, which enables an
    intense torture test of the RCU infratructure. This is needed due to the
    continued changes to the RCU infrastructure to accommodate dynamic ticks,
    CPU hotplug, realtime, and so on. Most of the code is in a separate file
    that is compiled only if the CONFIG variable is set. Documentation on how
    to run the test and interpret the output is also included.

    This code has been tested on i386 and ppc64, and an earlier version of the
    code has received extensive testing on a number of architectures as part of
    the PREEMPT_RT patchset.

    Signed-off-by: "Paul E. McKenney"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

11 Sep, 2005

1 commit


10 Sep, 2005

1 commit

  • Adds a set of primitives to do reference counting for objects that are looked
    up without locks using RCU.

    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Dipankar Sarma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     

08 Sep, 2005

1 commit

  • Uses of RCU for dynamically changeable NMI handlers need to use the new
    rcu_dereference() and rcu_assign_pointer() facilities. This change makes
    it clear that these uses are safe from a memory-barrier viewpoint, but the
    main purpose is to document exactly what operations are being protected by
    RCU. This has been tested on x86 and x86-64, which are the only
    architectures affected by this change.

    Signed-off-by:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

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