From: Pingfan Liu <kernelfans@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: rcu@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
Frederic Weisbecker <frederic@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCHv2 2/2] srcu: Eliminate the case that snp_seq bigger than snap in srcu_funnel_gp_start()
Date: Fri, 25 Nov 2022 20:37:03 +0800 [thread overview]
Message-ID: <Y4C271JOvsKU+ckG@piliu.users.ipa.redhat.com> (raw)
In-Reply-To: <20221124161926.GA3495117@paulmck-ThinkPad-P17-Gen-1>
On Thu, Nov 24, 2022 at 08:19:26AM -0800, Paul E. McKenney wrote:
> On Wed, Nov 23, 2022 at 09:24:17PM -0800, Paul E. McKenney wrote:
> > On Thu, Nov 24, 2022 at 12:06:39PM +0800, Pingfan Liu wrote:
> > > On Thu, Nov 24, 2022 at 11:33 AM Pingfan Liu <kernelfans@gmail.com> wrote:
> > > >
> > > > On Wed, Nov 23, 2022 at 11:20:46AM -0800, Paul E. McKenney wrote:
> > > > > On Wed, Nov 23, 2022 at 09:56:38PM +0800, Pingfan Liu wrote:
> > > > > > Since the srcu read lock is still held during srcu_funnel_gp_start(),
> > > > > > the seq snap should be the largest number for the slot
> > > > > > srcu_have_cbs[idx].
> > > > > >
> > > > > > Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> > > > > > Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> > > > > > Cc: "Paul E. McKenney" <paulmck@kernel.org>
> > > > > > Cc: Frederic Weisbecker <frederic@kernel.org>
> > > > > > Cc: Josh Triplett <josh@joshtriplett.org>
> > > > > > Cc: Steven Rostedt <rostedt@goodmis.org>
> > > > > > Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > > > > > To: rcu@vger.kernel.org
> > > > > > ---
> > > > > > include/linux/rcupdate.h | 1 +
> > > > > > kernel/rcu/srcutree.c | 11 ++++++-----
> > > > > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > > > index 08605ce7379d..a09007236660 100644
> > > > > > --- a/include/linux/rcupdate.h
> > > > > > +++ b/include/linux/rcupdate.h
> > > > > > @@ -32,6 +32,7 @@
> > > > > > #include <linux/context_tracking_irq.h>
> > > > > >
> > > > > > #define ULONG_CMP_GE(a, b) (ULONG_MAX / 2 >= (a) - (b))
> > > > > > +#define ULONG_CMP_GT(a, b) (ULONG_MAX / 2 > (a) - (b))
> > > > >
> > > > > Please see below...
> > > > >
> > > > > > #define ULONG_CMP_LT(a, b) (ULONG_MAX / 2 < (a) - (b))
> > > > > > #define ulong2long(a) (*(long *)(&(a)))
> > > > > > #define USHORT_CMP_GE(a, b) (USHRT_MAX / 2 >= (unsigned short)((a) - (b)))
> > > > > > diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
> > > > > > index 2fc0e775ade4..41902b823687 100644
> > > > > > --- a/kernel/rcu/srcutree.c
> > > > > > +++ b/kernel/rcu/srcutree.c
> > > > > > @@ -905,14 +905,15 @@ static void srcu_funnel_gp_start(struct srcu_struct *ssp, struct srcu_data *sdp,
> > > > > > for (snp = snp_leaf; snp != NULL; snp = snp->srcu_parent) {
> > > > > > spin_lock_irqsave_rcu_node(snp, flags);
> > > > > > snp_seq = snp->srcu_have_cbs[idx];
> > > > > > - if (!srcu_invl_snp_seq(snp_seq) && ULONG_CMP_GE(snp_seq, s)) {
> > > > > > + /*
> > > > > > + * s should be the biggest in the current slot. Hence only LE is
> > > > > > + * valid
> > > > > > + */
> > > > > > + BUG_ON(ULONG_CMP_GT(snp_seq, s));
> > > > >
> > > > > Why not this? (Plus adjusting the comment above, of course.)
> > > > >
> > > > > WARN_ON_ONCE(ULONG_CMP_LT(s, snp_seq));
> > > > >
> > > >
> > > > A neat solution!
> > > >
> > > > And what about the comment
> > > > /* s should be the biggest in the current slot. */
> > > >
> > > > > That way we don't need ULONG_CMP_GT(). Plus if we are confused about
> > > > > s being the biggest in the current slot, we get a splat and can debug
> > > > > further. We both might be quite sure that we are not confused, but
> > > > > that is exactly when we are most prone to making mistakes. ;-)
> > > > >
> > > >
> > > > Same feeling :)
> > > >
> > > > > I also ask that you run with this check for some time. After all, if
> > >
> > > Forget to ask if the test
> > > "tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration
> > > 10h --configs 18*SRCU-P"
> > > satisfies your requirement?
> >
> > I am thinking more in terms of adding the WARN_ON_ONCE(), letting it be
> > in -next and possibly mainline for a couple of years, and then if there
> > are no splats, start feeling more confident in the asserted relationship.
> >
> > If there was a significant performance, scalability, energy-efficiency, or
> > simplification benefit, I would feel justified in being more aggressive.
> >
> > But I am not seeing a significant benefit.
>
> Ah, and before I forget -again-, have you thought through the counter-wrap
> scenarios? Please keep in mind that on a 32-bit system, those counters
> can wrap quite quickly compared to typical uptimes.
>
I think 32-bit has not significant different since the statement
WARN_ON_ONCE(ULONG_CMP_LT(s, snp_seq));
where 's < snp_seq' is not associated with bits. Am I missing anything?
Thanks,
Pingfan
> Thanx, Paul
>
> > > Thanks
> > >
> > > Pingfan
> > > > Sure. I will try it immediately.
> > > >
> > > > > the assumption is incorrect, the resulting SRCU hangs off in various
> > > > > systems around the world will not be so much fun to debug.
> > > > >
> > > > > Given that this is slowpath code, it is much better to take an extra
> > > > > compare and branch than to introduce even an extremely small risk of
> > > > > hanging SRCU.
> > > > >
> > > >
> > > > Agree.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Pingfan
> > > >
> > > > > Thanx, Paul
> > > > >
> > > > > > + if (!srcu_invl_snp_seq(snp_seq) && (snp_seq == s)) {
> > > > > > if (snp == snp_leaf && snp_seq == s)
> > > > > > snp->srcu_data_have_cbs[idx] |= sdp->grpmask;
> > > > > > spin_unlock_irqrestore_rcu_node(snp, flags);
> > > > > > - if (snp == snp_leaf && snp_seq != s) {
> > > > > > - srcu_schedule_cbs_sdp(sdp, do_norm ? SRCU_INTERVAL : 0);
> > > > > > - return;
> > > > > > - }
> > > > > > if (!do_norm)
> > > > > > srcu_funnel_exp_start(ssp, snp, s);
> > > > > > return;
> > > > > > --
> > > > > > 2.31.1
> > > > > >
next prev parent reply other threads:[~2022-11-25 12:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 13:56 [PATCHv2 0/2] srcu: Optimize when srcu_gp_start_if_needed() holds read lock Pingfan Liu
2022-11-23 13:56 ` [PATCHv2 1/2] srcu: Remove needless rcu_seq_done() check while holding " Pingfan Liu
2022-11-28 23:57 ` Paul E. McKenney
2022-11-23 13:56 ` [PATCHv2 2/2] srcu: Eliminate the case that snp_seq bigger than snap in srcu_funnel_gp_start() Pingfan Liu
2022-11-23 19:20 ` Paul E. McKenney
2022-11-24 3:33 ` Pingfan Liu
2022-11-24 4:06 ` Pingfan Liu
2022-11-24 5:24 ` Paul E. McKenney
2022-11-24 16:19 ` Paul E. McKenney
2022-11-25 12:37 ` Pingfan Liu [this message]
2022-11-26 18:03 ` Paul E. McKenney
2022-11-26 18:07 ` Paul E. McKenney
2022-11-27 14:46 ` Joel Fernandes
2022-11-27 17:55 ` Paul E. McKenney
2022-11-27 15:01 ` Pingfan Liu
2022-11-27 18:00 ` Paul E. McKenney
2022-11-28 7:59 ` Pingfan Liu
2022-11-29 0:37 ` Paul E. McKenney
2022-11-25 12:32 ` Pingfan Liu
2022-11-25 12:46 ` [PATCHv3] " Pingfan Liu
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=Y4C271JOvsKU+ckG@piliu.users.ipa.redhat.com \
--to=kernelfans@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.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.