[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180829214750.26972-7-paulmck@linux.vnet.ibm.com>
Date: Wed, 29 Aug 2018 14:47:40 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: linux-kernel@...r.kernel.org
Cc: mingo@...nel.org, jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: [PATCH tip/core/rcu 07/17] rcutorture: Also use GP sequence to judge forward progress
Currently, rcutorture relies solely on the progress of
rcu_torture_writer() to judge grace-period forward progress. In theory,
this is the gold standard of forward progress, but in practice rcutorture
separately detects and reports rcu_torture_writer() stalls. This commit
therefore adds the grace-period sequence number (when provided) to the
judgment of grace-period forward progress, which makes it easier to
distinguish between failure of actual grace periods to progress on the
one hand and downstream forward-progress failures on the other.
For example, given this change, if rcu_torture_writer() stalls,
but rcu_torture_fwd_prog() does not complain, then the grace-period
computation is working, which is a hint that the failure lies in callback
processing, wakeup of the rcu_torture_writer() kthread, or similar.
Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
---
kernel/rcu/rcutorture.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index fd3ce6cc8eea..dee7b45b2186 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -1673,7 +1673,8 @@ static int __init rcu_torture_stall_init(void)
/* Carry out grace-period forward-progress testing. */
static int rcu_torture_fwd_prog(void *args)
{
- unsigned long cvar;
+ unsigned long cver;
+ unsigned long gps;
int idx;
unsigned long stopat;
bool tested = false;
@@ -1681,7 +1682,8 @@ static int rcu_torture_fwd_prog(void *args)
VERBOSE_TOROUT_STRING("rcu_torture_fwd_progress task started");
do {
schedule_timeout_interruptible(fwd_progress_holdoff * HZ);
- cvar = READ_ONCE(rcu_torture_current_version);
+ cver = READ_ONCE(rcu_torture_current_version);
+ gps = cur_ops->get_gp_seq();
stopat = jiffies + cur_ops->stall_dur() / fwd_progress_div;
while (time_before(jiffies, stopat) && !torture_must_stop()) {
idx = cur_ops->readlock();
@@ -1692,8 +1694,9 @@ static int rcu_torture_fwd_prog(void *args)
}
if (!time_before(jiffies, stopat) && !torture_must_stop()) {
tested = true;
- WARN_ON_ONCE(cvar ==
- READ_ONCE(rcu_torture_current_version));
+ cver = cver == READ_ONCE(rcu_torture_current_version);
+ gps = rcutorture_seq_diff(cur_ops->get_gp_seq(), gps);
+ WARN_ON_ONCE(cver && gps < 2);
}
/* Avoid slow periods, better to test when busy. */
stutter_wait("rcu_torture_fwd_prog");
--
2.17.1
Powered by blists - more mailing lists