public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Joel Fernandes <joelagnelf@nvidia.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Davidlohr Bueso <dave@stgolabs.net>, rcu <rcu@vger.kernel.org>
Subject: Re: rcutorture: Perform more frequent testing of ->gpwrap
Date: Thu, 10 Apr 2025 13:48:50 -0000	[thread overview]
Message-ID: <174429293067.108.13577356830876647003@patchwork.local> (raw)
In-Reply-To: <93682939-6e82-43e7-8681-cc84539d9bc0@paulmck-laptop>

Hello, Paul,

On Thu, 10 Apr 2025 13:35:35 GMT, "Paul E. McKenney" wrote:
[...]
> > > >  kernel/rcu/rcu.h        |  4 +++
> > > >  kernel/rcu/rcutorture.c | 64 ++++++++++++++++++++++++++++++++++++++++
> > > >  kernel/rcu/tree.c       | 34 ++++++++++++++++++++--
> > > >  kernel/rcu/tree.h       |  1 +
> > > >  4 files changed, 101 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > > > index eed2951a4962..9a15e9701e02 100644
> > > > --- a/kernel/rcu/rcu.h
> > > > +++ b/kernel/rcu/rcu.h
> > > > @@ -572,6 +572,8 @@ void do_trace_rcu_torture_read(const char *rcutort
> > > >  			       unsigned long c_old,
> > > >  			       unsigned long c);
> > > >  void rcu_gp_set_torture_wait(int duration);
> > > > +void rcu_set_torture_ovf_lag(unsigned long lag);
> > > > +int rcu_get_gpwrap_count(int cpu);
> > > >  #else
> > > >  static inline void rcutorture_get_gp_data(int *flags, unsigned long *
> > > >  {
> > > > @@ -589,6 +591,8 @@ void do_trace_rcu_torture_read(const char *rcutort
> > > >  	do { } while (0)
> > > >  #endif
> > > >  static inline void rcu_gp_set_torture_wait(int duration) { }
> > > > +static inline void rcu_set_torture_ovf_lag(unsigned long lag) { }
> > > > +static inline int rcu_get_gpwrap_count(int cpu) { return 0; }
> > > 
> > > Very good, you did remember CONFIG_SMP=n.  And yes, I did try it.  ;-)
> > > 
> > > But shouldn't these be function pointers in rcu_torture_ops?  That way if
> > > some other flavor of RCU starts doing wrap protection for its grace-period
> > > sequence numbers, this testing can apply directly to that flavor as well.
> > 
> > These are here because 'rdp' is not accessible AFAIK from rcutorture.c.
> > I could add wrappers to these and include them as pointers the a struct as well.
> > But I think these will still stay to access rdp.
> 
> Why not just pass in the CPU number and let the pointed-to function find
> the rdp?

Great, I did this and it looks good now, will post v2 shortly.

> > > I could argue with the defaults, but I run long tests often enough that
> > > I am not worried about coverage.  As long as we remember to either run
> > > long tests or specify appropriate rcutorture.ovf_cycle_mins when messing
> > > with ->gpwrap code.
> > > 
> > > >  torture_param(int, nocbs_nthreads, 0, "Number of NOCB toggle threads,
> > > >  torture_param(int, nocbs_toggle, 1000, "Time between toggling nocb st
> ate (ms)");
> > > >  torture_param(int, preempt_duration, 0, "Preemption duration (ms), ze
> > > > @@ -2629,6 +2632,7 @@ rcu_torture_stats_print(void)
> > > >  	int i;
> > > >  	long pipesummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
> > > >  	long batchsummary[RCU_TORTURE_PIPE_LEN + 1] = { 0 };
> > > > +	long n_gpwraps = 0;
> > > >  	struct rcu_torture *rtcp;
> > > >  	static unsigned long rtcv_snap = ULONG_MAX;
> > > >  	static bool splatted;
> > > > @@ -2639,6 +2643,7 @@ rcu_torture_stats_print(void)
> > > >  			pipesummary[i] += READ_ONCE(per_cpu(rcu_torture_count, cpu)[i]);
> > > >  			batchsummary[i] += READ_ONCE(per_cpu(rcu_torture_batch, cpu)[i]);
> > > >  		}
> > > > +		n_gpwraps += rcu_get_gpwrap_count(cpu);
> > > >  	}
> > > >  	for (i = RCU_TORTURE_PIPE_LEN; i >= 0; i--) {
> > > >  		if (pipesummary[i] != 0)
> > > > @@ -2672,6 +2677,7 @@ rcu_torture_stats_print(void)
> > > >  	pr_cont("read-exits: %ld ", data_race(n_read_exits)); // Statistic.
> > > >  	pr_cont("nocb-toggles: %ld:%ld\n",
> > > 
> > > The "\n" on the above line needs to be deleted.
> > 
> > Ok.

Done.

> > 
> > > >  		atomic_long_read(&n_nocb_offload), atomic_long_read(&n_nocb_deofflo
> > > > +	pr_cont("gpwraps: %ld\n", n_gpwraps);
> > > >  
> > > >  	pr_alert("%s%s ", torture_type, TORTURE_FLAG);
> > > >  	if (atomic_read(&n_rcu_torture_mberror) ||
> > > > @@ -3842,6 +3848,58 @@ static int rcu_torture_preempt(void *unused)
> > > >  
> > > >  static enum cpuhp_state rcutor_hp;
> > > >  
> > > > +static struct hrtimer ovf_lag_timer;
> > > > +static bool ovf_lag_active;
> > > 
> > > Same "ovf" naming complaint as before.
> > 
> > Ok.

Done.

> > 
> > > > +}
> > > > +
> > > > +static int rcu_torture_ovf_lag_init(void)
> > > > +{
> > > > +	if (ovf_cycle_mins <= 0 || ovf_active_mins <= 0) {
> > > > +		pr_alert("rcu-torture: lag timing parameters must be positive\n");
> > > > +		return -EINVAL;
> > > > +	}
> > > 
> > > Why not refuse to start this portion of the test when CONFIG_SMP =n
> > > or something other than vanilla RCU?  No need to fail the test, just
> > > print something saying that this testing won't be happening.
> > 
> > Got it, will do.
> 
> Again, thank you!

I changed this to, something like:

	if (cur_ops->set_gpwrap_lag && rcu_gpwrap_lag_init())
		goto unwind;

So it will only test RCU flavor.

However, to your point - for TINY, we would still start the timer which will be
a NOOP.  But considering it is 5 minutes every 30 minutes, maybe that's Ok? ;-)
We could also have a ops pointer ->can_test_gpwrap_lag() which returns FALSE
for Tiny, but then it is adding more ops pointers.

thanks,

 - Joel

  parent reply	other threads:[~2025-04-10 13:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-29 23:01 [PATCH] rcutorture: Perform more frequent testing of ->gpwrap Joel Fernandes
2025-04-02  1:16 ` Paul E. McKenney
2025-04-05 12:30   ` Joel Fernandes
2025-04-05 17:22     ` Paul E. McKenney
2025-04-05 17:54       ` Joel Fernandes
2025-04-05 19:09         ` Paul E. McKenney
2025-04-10 13:48       ` Joel Fernandes [this message]
2025-04-10 13:48       ` Joel Fernandes

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=174429293067.108.13577356830876647003@patchwork.local \
    --to=joelagnelf@nvidia.com \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=neeraj.upadhyay@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=qiang.zhang1211@gmail.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=urezki@gmail.com \
    /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