From: "Paul E. McKenney" <paulmck@kernel.org>
To: Joel Fernandes <joelagnelf@nvidia.com>
Cc: rcu@vger.kernel.org
Subject: Re: The rdp->gpwrap behavior
Date: Wed, 19 Feb 2025 09:02:11 -0800 [thread overview]
Message-ID: <fcb3ea88-9c11-4bbb-8eb9-480935da0703@paulmck-laptop> (raw)
In-Reply-To: <7dd7431d-a8d9-4ac1-9c28-e43c7c1fcbce@nvidia.com>
On Wed, Feb 19, 2025 at 10:57:29AM -0500, Joel Fernandes wrote:
> On 2/19/2025 8:54 AM, Paul E. McKenney wrote:
> >>> the system, by scaling the default by the number of CPUs. After all,
> >>> we want to test both the ->gpwrap path *and* the non-->gpwrap path.
> >> Agreed. But do we want to test both these paths only under rcutorture testing or
> >> were you considering we do it for regular operation as well? i.e. wrap in 10
> >> minutes in regular operation. I am guessing you want it only for rcutorture
> >> _and_ have a 10 minute default.
> >>
> >> If that is the case, we would then need rcu_gpnum_ovf() to consult rcutorture,
> >> if it is enabled, about what what the threshold is.
> > The rcu_gp_slow() function does something similar for the grace-period
> > kthread's injected delays, so that can work. Probably better than putting
> > the module parameter in tree.c, because putting it in rcutorture makes
> > in more clear that it is for debugging.
>
> Ok thanks, just to clarify:
>
> Normal operation is still ULONG/2 threshold.
Yes, please keep this be the default.
> rcutorture operation will be 10 minutes (overridable by rcutorture module
> option, not module option in non-test kernel code itself).
That sounds good also.
> If we are in disagreement about this, please let me know. Otherwise I will work
> on a patch as a next step on this.
Very good, looking forward to seeing what you come up with!
Thanx, Paul
prev parent reply other threads:[~2025-02-19 17:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 18:30 The rdp->gpwrap behavior Joel Fernandes
2025-02-14 8:20 ` Paul E. McKenney
2025-02-14 18:03 ` Joel Fernandes
2025-02-15 10:28 ` Paul E. McKenney
2025-02-16 12:23 ` Joel Fernandes
2025-02-18 13:17 ` Paul E. McKenney
2025-02-18 22:50 ` Joel Fernandes
2025-02-19 13:54 ` Paul E. McKenney
2025-02-19 15:57 ` Joel Fernandes
2025-02-19 17:02 ` Paul E. McKenney [this message]
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=fcb3ea88-9c11-4bbb-8eb9-480935da0703@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=joelagnelf@nvidia.com \
--cc=rcu@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.