lkml.org 
[lkml]   [2014]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH tip/core/rcu 01/45] rcutorture: Add forward-progress checking for writer
    On Fri, May 09, 2014 at 08:52:31AM -0700, Josh Triplett wrote:
    > On Wed, May 07, 2014 at 04:43:13PM -0700, Paul E. McKenney wrote:
    > > On Wed, May 07, 2014 at 02:16:49PM -0700, josh@joshtriplett.org wrote:
    > > > On Mon, Apr 28, 2014 at 05:24:49PM -0700, Paul E. McKenney wrote:
    > > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
    > > > >
    > > > > The rcutorture output currently does not distinguish between stalls in
    > > > > the RCU implementation and stalls in the rcu_torture_writer() kthreads.
    > > > > This commit therefore adds some diagnostics to help distinguish between
    > > > > these two conditions, at least for the non-SRCU implementations. (SRCU
    > > > > does not provide evidence of update-side forward progress by design.)
    > > > >
    > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    > > >
    > > > The concept makes sense, and the writer state annotations seem like a
    > > > useful debugging mechanism, but having RCU know about RCU torture types
    > > > seems fundamentally wrong. This mechanism accesses rcu_state, which is
    > > > already implementation-specific, so why not just only define the
    > > > function for the RCU implementations that support it, and then have a
    > > > function pointer in the torture-test structure to report a stall?
    > >
    > > Ouch. It is worse than that! When running RCU-bh or RCU-sched,
    > > the current code incorrectly returns the statistics for RCU.
    > > So I do need some way for rcutorture to tell RCU which flavor
    > > it is testing.
    > >
    > > One thing I could do would be to pass in a pointer to the call_rcu()
    > > function (cur_ops->call from rcutorture's viewpoint), then scan the
    > > rcu_state structures looking for the selected flavor (rsp->call from
    > > tree.c's viewpoint). In the SRCU and RCU-busted cases, the flavor would
    > > not be found, and I could then just set everything to zero.
    > >
    > > Does that seem reasonable, or is there a better way to do this?
    >
    > That search seems rather too hackish; why not just declare one
    > stats-returning function per RCU flavor, and put the pointer to the
    > corresponding function in the structure for each test type?

    The problem is that rcutorture doesn't know anything about the structures,
    as those are internal to the implementation. All it knows is which
    functions it is using. I -could- EXPORT_SYMBOL_GPL() the rcu_state
    structures to modules (they are already non-static), then rename
    TINY_RCU's rcu_ctrlblk to rcu_state to allow the needed type punning,
    then do some special-case thing for SRCU, and put a pointer to whatever
    in rcu_torture_ops, but that was feeling a bit hackish as well.

    So what did you have in mind to allow rcutorture to communicate the
    rcuflavor to the underlying RCU implementation?

    Thanx, Paul



    \
     
     \ /
      Last update: 2014-05-09 20:21    [W:2.758 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site