From: Uladzislau Rezki <urezki@gmail.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
RCU <rcu@vger.kernel.org>,
Neeraj upadhyay <Neeraj.Upadhyay@amd.com>,
Boqun Feng <boqun.feng@gmail.com>,
Hillf Danton <hdanton@sina.com>,
Joel Fernandes <joel@joelfernandes.org>,
LKML <linux-kernel@vger.kernel.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>
Subject: Re: [PATCH v4 1/4] rcu: Reduce synchronize_rcu() latency
Date: Thu, 18 Jan 2024 11:37:11 +0100 [thread overview]
Message-ID: <Zaj_Vw8B5E28TqZ2@pc636> (raw)
In-Reply-To: <ZaHGv3wMYP4LDCxG@localhost.localdomain>
On Sat, Jan 13, 2024 at 12:09:51AM +0100, Frederic Weisbecker wrote:
> Le Thu, Jan 04, 2024 at 05:25:07PM +0100, Uladzislau Rezki (Sony) a écrit :
> > diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
> > index 9b0b52e1836f..4812c6249185 100644
> > --- a/kernel/rcu/Kconfig.debug
> > +++ b/kernel/rcu/Kconfig.debug
> > @@ -168,4 +168,16 @@ config RCU_STRICT_GRACE_PERIOD
> > when looking for certain types of RCU usage bugs, for example,
> > too-short RCU read-side critical sections.
> >
> > +config RCU_SR_NORMAL_DEBUG_GP
> > + bool "Debug synchronize_rcu() callers for a grace period completion"
> > + depends on DEBUG_KERNEL && RCU_EXPERT
> > + default n
> > + help
> > + This option enables additional debugging for detecting a grace
> > + period incompletion for synchronize_rcu() users. If a GP is not
> > + fully passed for any user, the warning message is emitted.
> > +
> > + Say Y here if you want to enable such debugging
> > + Say N if you are unsure.
>
> How about just reuse CONFIG_PROVE_RCU instead?
>
Less extra CONFIG_* configuration we have the better approach is. I do
not mind, so we can reuse it. Thanks for this point :)
I see in some places indeed it is used as a debugging peace.
> > +
> > endmenu # "RCU Debugging"
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 499803234176..b756c40e4960 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -1422,6 +1422,106 @@ static void rcu_poll_gp_seq_end_unlocked(unsigned long *snap)
> > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > }
> >
> > +/*
> > + * There are three lists for handling synchronize_rcu() users.
> > + * A first list corresponds to new coming users, second for users
> > + * which wait for a grace period and third is for which a grace
> > + * period is passed.
> > + */
> > +static struct sr_normal_state {
> > + struct llist_head srs_next; /* request a GP users. */
> > + struct llist_head srs_wait; /* wait for GP users. */
> > + struct llist_head srs_done; /* ready for GP users. */
> > +
> > + /*
> > + * In order to add a batch of nodes to already
> > + * existing srs-done-list, a tail of srs-wait-list
> > + * is maintained.
> > + */
> > + struct llist_node *srs_wait_tail;
> > +} sr;
>
> "sr" is good enough for a function scope variable but not for a file scope one.
>
> At least "sr_state" would be better. Or maybe you don't even need to name that
> struct and make instead:
>
> struct {
> ...
> ...
> } sr_normal_state;
>
It is moved by the following patch in the series under the "rcu_state" struct variable.
>
> > +
> > +/* Disabled by default. */
> > +static int rcu_normal_wake_from_gp;
> > +module_param(rcu_normal_wake_from_gp, int, 0644);
> > +
> > +static void rcu_sr_normal_complete(struct llist_node *node)
> > +{
> > + struct rcu_synchronize *rs = container_of(
> > + (struct rcu_head *) node, struct rcu_synchronize, head);
>
> Should there be some union in struct rcu_synchronize between struct rcu_head
> and struct llist_node?
>
> Anyway it's stack allocated, they could even be separate fields.
>
> > + unsigned long oldstate = (unsigned long) rs->head.func;
>
> Luckily struct callback_head layout allows such magic but if rcu_head
> and llist_node were separate, reviewers would be less hurt.
>
> If stack space really matters, something like the below?
>
> struct rcu_synchronize {
> union {
> struct rcu_head head;
> struct {
> struct llist_node node;
> unsigned long seq;
> }
> }
> struct completion completion;
> };
>
>
We can do that. I am not sure if should be a separate patch or as a big
change. I tend to separate it.
> > +
> > + WARN_ONCE(IS_ENABLED(CONFIG_RCU_SR_NORMAL_DEBUG_GP) &&
> > + !poll_state_synchronize_rcu(oldstate),
> > + "A full grace period is not passed yet: %lu",
> > + rcu_seq_diff(get_state_synchronize_rcu(), oldstate));
> > +
> > + /* Finally. */
> > + complete(&rs->completion);
> > +}
> > +
> [...]
> > +
> > +/*
> > + * Helper function for rcu_gp_cleanup().
> > + */
> > +static void rcu_sr_normal_gp_cleanup(void)
> > +{
> > + struct llist_node *head, *tail;
> > +
> > + if (llist_empty(&sr.srs_wait))
> > + return;
> > +
> > + tail = READ_ONCE(sr.srs_wait_tail);
>
> Is the READ_ONCE() needed?
>
> A part from those boring details:
>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
>
Appreciate for the review. I will fix all the comments.
Thanks!
--
Uladzislau Rezki
next prev parent reply other threads:[~2024-01-18 10:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 16:25 [PATCH v4 0/4] Reduce synchronize_rcu() latency(v4) Uladzislau Rezki (Sony)
2024-01-04 16:25 ` [PATCH v4 1/4] rcu: Reduce synchronize_rcu() latency Uladzislau Rezki (Sony)
2024-01-09 19:16 ` Kalesh Singh
2024-01-10 9:21 ` Uladzislau Rezki
2024-01-11 16:37 ` Kalesh Singh
2024-01-11 17:35 ` Uladzislau Rezki
2024-01-12 23:09 ` Frederic Weisbecker
2024-01-18 10:37 ` Uladzislau Rezki [this message]
2024-01-16 16:18 ` Paul E. McKenney
2024-01-17 12:26 ` Uladzislau Rezki
2024-01-19 15:24 ` Paul E. McKenney
2024-01-22 17:35 ` Uladzislau Rezki
2024-01-23 11:21 ` Paul E. McKenney
2024-01-04 16:25 ` [PATCH v4 2/4] rcu: Add a trace event for synchronize_rcu_normal() Uladzislau Rezki (Sony)
2024-01-12 23:20 ` Frederic Weisbecker
2024-01-15 12:14 ` Uladzislau Rezki
2024-01-04 16:25 ` [PATCH v4 3/4] rcu: Improve handling of synchronize_rcu() users Uladzislau Rezki (Sony)
2024-01-16 16:32 ` Paul E. McKenney
2024-01-04 16:25 ` [PATCH v4 4/4] rcu: Support direct wake-up " Uladzislau Rezki (Sony)
2024-01-13 9:19 ` Z qiang
2024-01-15 10:46 ` Uladzislau Rezki
2024-01-15 10:57 ` Uladzislau Rezki
2024-01-16 6:19 ` Z qiang
2024-01-27 7:07 ` [PATCH v4 0/4] Reduce synchronize_rcu() latency(v4) Paul E. McKenney
2024-01-29 16:23 ` Uladzislau Rezki
2024-01-29 19:43 ` Paul E. McKenney
2024-01-29 20:36 ` Uladzislau Rezki
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=Zaj_Vw8B5E28TqZ2@pc636 \
--to=urezki@gmail.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=hdanton@sina.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksiy.avramchenko@sony.com \
--cc=paulmck@kernel.org \
--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.