[3/3] rcu: Force quiescent states only for ongoing grace period

Commit Message

Neeraj upadhyay Dec. 12, 2023, 5:40 p.m. UTC

From: Zqiang <[e-mail]>

If an rcutorture test scenario creates an fqs_task kthread, it will
periodically invoke rcu_force_quiescent_state() in order to start
force-quiescent-state (FQS) operations.  However, an FQS operation
will be started even if there is no RCU grace period in progress.
Although testing FQS operations startup when there is no grace period in
progress is necessary, it need not happen all that often.  This commit
therefore causes rcu_force_quiescent_state() to take an early exit
if there is no grace period in progress.

Note that there will still be attempts to start an FQS scan in the
absence of a grace period because the grace period might end right
after the rcu_force_quiescent_state() function's check.  In actual
testing, this happens about once every ten minutes, which should
provide adequate testing.

Signed-off-by: Zqiang <[e-mail]>
Signed-off-by: Paul E. McKenney <[e-mail]>
Signed-off-by: Neeraj Upadhyay (AMD) <[e-mail]>
---
 kernel/rcu/tree.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Joel Fernandes Dec. 12, 2023, 11:22 p.m. UTC | #1

On Tue, Dec 12, 2023 at 12:40 PM Neeraj Upadhyay (AMD)
<[e-mail]> wrote:
>
> From: Zqiang <[e-mail]>
>
> If an rcutorture test scenario creates an fqs_task kthread, it will
> periodically invoke rcu_force_quiescent_state() in order to start
> force-quiescent-state (FQS) operations.  However, an FQS operation
> will be started even if there is no RCU grace period in progress.
> Although testing FQS operations startup when there is no grace period in
> progress is necessary, it need not happen all that often.  This commit
> therefore causes rcu_force_quiescent_state() to take an early exit
> if there is no grace period in progress.
>
> Note that there will still be attempts to start an FQS scan in the
> absence of a grace period because the grace period might end right
> after the rcu_force_quiescent_state() function's check.  In actual
> testing, this happens about once every ten minutes, which should
> provide adequate testing.
>
> Signed-off-by: Zqiang <[e-mail]>
> Signed-off-by: Paul E. McKenney <[e-mail]>
> Signed-off-by: Neeraj Upadhyay (AMD) <[e-mail]>
> ---
>  kernel/rcu/tree.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 3ac3c846105f..1ae851777806 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2338,6 +2338,8 @@ void rcu_force_quiescent_state(void)
>         struct rcu_node *rnp;
>         struct rcu_node *rnp_old = NULL;
>
> +       if (!rcu_gp_in_progress())
> +               return;

Reviewed-by: Joel Fernandes (Google) <[e-mail]>

(Probably no need to resend with the tag, just update the patch in the PR).

Thanks.

Patch

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3ac3c846105f..1ae851777806 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2338,6 +2338,8 @@  void rcu_force_quiescent_state(void)
 	struct rcu_node *rnp;
 	struct rcu_node *rnp_old = NULL;
 
+	if (!rcu_gp_in_progress())
+		return;
 	/* Funnel through hierarchy to reduce memory contention. */
 	rnp = raw_cpu_read(rcu_data.mynode);
 	for (; rnp != NULL; rnp = rnp->parent) {