linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
	rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
	fweisbec@gmail.com, oleg@redhat.com,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: [PATCH tip/core/rcu 09/12] torture: Default jitter off when running rcuperf
Date: Mon, 26 Feb 2018 14:02:38 -0800	[thread overview]
Message-ID: <1519682561-510-9-git-send-email-paulmck@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180226220225.GA32136@linux.vnet.ibm.com>

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 <paulmck@linux.vnet.ibm.com>
---
 tools/testing/selftests/rcutorture/bin/kvm.sh | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh b/tools/testing/selftests/rcutorture/bin/kvm.sh
index f3c3d33150a0..56610dbbdf73 100755
--- a/tools/testing/selftests/rcutorture/bin/kvm.sh
+++ b/tools/testing/selftests/rcutorture/bin/kvm.sh
@@ -179,6 +179,12 @@ do
 		checkarg --torture "(suite name)" "$#" "$2" '^\(lock\|rcu\|rcuperf\)$' '^--'
 		TORTURE_SUITE=$2
 		shift
+		if test "$TORTURE_SUITE" = rcuperf
+		then
+			# If you really want jitter for rcuperf, specify
+			# it after specifying rcuperf.  (But why?)
+			jitter=0
+		fi
 		;;
 	*)
 		echo Unknown argument $1
-- 
2.5.2

  parent reply	other threads:[~2018-02-26 22:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 22:02 [PATCH tip/core/rcu 0/12] Torture-test updates Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 01/12] rcutorture: Replace multi-instance kzalloc() with kcalloc() Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 02/12] rcutorture: Abstract function and module names Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 03/12] rcutorture: Avoid fake-writer use of undefined primitives Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 04/12] rcutorture: Re-enable testing of dynamic expediting Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 05/12] rcutorture: Record which grace-period primitives are tested Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 06/12] rcutorture: Update kvm.sh header comment Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 07/12] rcutorture: Add basic ARM64 support to run scripts Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 08/12] torture: Specify qemu memory size with --memory argument Paul E. McKenney
2018-02-26 22:02 ` Paul E. McKenney [this message]
2018-02-26 22:02 ` [PATCH tip/core/rcu 10/12] torture: Adjust rcuperf trace processing to allow for workqueues Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 11/12] torture: Grace periods do not piggyback off of themselves Paul E. McKenney
2018-02-26 22:02 ` [PATCH tip/core/rcu 12/12] torture: Provide more sensible nreader/nwriter defaults for rcuperf Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1519682561-510-9-git-send-email-paulmck@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).