linux-toradex.git/tools/testing/selftests/rcutorture, branch v4.18

torture: Make kvm-find-errors.sh find build warnings

2018-05-15T17:32:25+00:00

Currently, kvm-find-errors.sh looks only for build errors ("error:"),
so this commit makes it also locate build warnings ("warning:").

Signed-off-by: Paul E. McKenney 
Tested-by: Nicholas Piggin

rcutorture: Abbreviate kvm.sh summary lines

2018-05-15T17:32:17+00:00

With the addition of the end-of-test state, it is not uncommon for the
kvm.sh summary lines to overflow 80 characters.  This commit therefore
applies abbreviations in order to make the line fit into 80 characters
with high probability.

And yes, I did make heavy use of punched cards back in the day, so 80
columns it is for my xterms!  ;-)

Signed-off-by: Paul E. McKenney 
Tested-by: Nicholas Piggin

rcutorture: Print end-of-test state in kvm.sh summary

2018-05-15T17:32:13+00:00

This commit adds the end-of-test test, if present in the console output,
to the kvm.sh test summary that is printed by kvm-recheck.sh.  Note that
this only applies to rcutorture console output.

Signed-off-by: Paul E. McKenney 
Tested-by: Nicholas Piggin

torture: Fold parse-torture.sh into parse-console.sh

2018-05-15T17:32:04+00:00

The rcutorture scripting scans the console output twice, once to look
for various sorts of hangs and again to find warnings and panics.
Unfortunately, only the output of the second scan gets written to the
console.log.diags file, which can cause hangs to be overlooked.
This commit therefore folds the parse-torture.sh script (which looks
for hangs) into the parse-console.sh script (which looks for warnings
and panics).  This allows both types of failure information to be
added to console.log.diags, while still reliably removing this file
when it proves to be empty.

This also fixes a long-standing bug where rcuperf log files would
unconditionally complain about a hang.

Signed-off-by: Paul E. McKenney 
Tested-by: Nicholas Piggin

torture: Add a script to edit output from failed runs

2018-05-15T17:31:52+00:00

This commit adds a script that allows viewing the build and/or
console output from failed rcutorture, locktorture, or rcuperf runs.
This replaces a time-honored but inefficient manual procedure that uses
cut and paste.

Signed-off-by: Paul E. McKenney 
Tested-by: Nicholas Piggin

Merge branches 'fixes.2018.02.23a', 'srcu.2018.02.20a' and 'torture.2018.02.20a' into HEAD

2018-02-23T23:15:41+00:00

fixes.2018.02.23a: Miscellaneous fixes
srcu.2018.02.20a: SRCU updates
torture.2018.02.20a: Torture-test updates

torture: Provide more sensible nreader/nwriter defaults for rcuperf

2018-02-21T00:22:01+00:00

The default values for nreader and nwriter are apparently not all that
user-friendly, resulting in people doing scalability tests that ran all
runs at large scale.  This commit therefore makes both the nreaders and
nwriters module default to the number of CPUs, and adds a comment to
rcuperf.c stating that the number of CPUs should be specified using the
nr_cpus kernel boot parameter.  This commit also eliminates the redundant
rcuperf scripting specification of default values for these parameters.

Signed-off-by: Paul E. McKenney

torture: Grace periods do not piggyback off of themselves

2018-02-21T00:22:01+00:00

The rcuperf trace-event processing counted every "done" trace event
as a piggyback, which is incorrect because the task that started the
grace period didn't piggyback at all.  This commit fixes this problem
by recording the task that started a given grace period and ignoring
that task's "done" record for that grace period.

Signed-off-by: Paul E. McKenney

torture: Adjust rcuperf trace processing to allow for workqueues

2018-02-21T00:22:00+00:00

The rcuperf event-trace processing assumes that expedited grace periods
start and end on the same task, an assumption that was violated by moving
expedited grace-period processing to workqueues.  This commit removes
this now-fallacious assumption from rcuperf's event-trace processing.

Signed-off-by: Paul E. McKenney

torture: Default jitter off when running rcuperf

2018-02-21T00:22:00+00:00

The purpose of jitter is to expose concurrency bugs due to invalid
assumptions about forward progress.  There is usually little point
in jitter when measuring performance.  This commit therefore defaults
jitter off when running rcuperf.  You can override this by specifying
the kvm.sh "--jitter" argument -after- the "--torture rcuperf"
argument.  No idea why you would want this, but if you do, that is
how you do it.

One example of a conccurrency bug that this jitter might expose is one
in which the developer assumed that a given short region of code would be
guaranteed to execute within some short time limit.  Such assumptions are
invalid in virtualized environments because the hupervisor can preempt
the guest OS at any point, even when the guest OS thinks that it has
disabled interrupts.

Signed-off-by: Paul E. McKenney