KVM Archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Leonardo Bras <leobras@redhat.com>
Cc: Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <quic_neeraju@quicinc.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	rcu@vger.kernel.org
Subject: Re: [RFC PATCH v1 0/2] Avoid rcu_core() if CPU just left guest vcpu
Date: Thu, 9 May 2024 16:45:53 -0700	[thread overview]
Message-ID: <09a8f4f6-a692-4586-bb68-b0a524b7a5d8@paulmck-laptop> (raw)
In-Reply-To: <Zjyh-qRt3YewHsdP@LeoBras>

On Thu, May 09, 2024 at 07:14:18AM -0300, Leonardo Bras wrote:
> On Thu, May 09, 2024 at 05:16:57AM -0300, Leonardo Bras wrote:

[ . . . ]

> > Here I suppose something like this can take care of not needing to convert 
> > ms -> jiffies every rcu_pending():
> > 
> > +	nocb_patience_delay = msecs_to_jiffies(nocb_patience_delay);
> > 
> 
> Uh, there is more to it, actually. We need to make sure the user 
> understands that we are rounding-down the value to multiple of a jiffy 
> period, so it's not a surprise if the delay value is not exactly the same 
> as the passed on kernel cmdline.
> 
> So something like bellow diff should be ok, as this behavior is explained 
> in the docs, and pr_info() will print the effective value.
> 
> What do you think?

Good point, and I have taken your advice on making the documentation
say what it does.

> Thanks!
> Leo
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 0a3b0fd1910e..9a50be9fd9eb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4974,20 +4974,28 @@
>                         otherwise be caused by callback floods through
>                         use of the ->nocb_bypass list.  However, in the
>                         common non-flooded case, RCU queues directly to
>                         the main ->cblist in order to avoid the extra
>                         overhead of the ->nocb_bypass list and its lock.
>                         But if there are too many callbacks queued during
>                         a single jiffy, RCU pre-queues the callbacks into
>                         the ->nocb_bypass queue.  The definition of "too
>                         many" is supplied by this kernel boot parameter.
>  
> +       rcutree.nocb_patience_delay= [KNL]
> +                       On callback-offloaded (rcu_nocbs) CPUs, avoid
> +                       disturbing RCU unless the grace period has
> +                       reached the specified age in milliseconds.
> +                       Defaults to zero.  Large values will be capped
> +                       at five seconds. Values rounded-down to a multiple
> +                       of a jiffy period.
> +
>         rcutree.qhimark= [KNL]
>                         Set threshold of queued RCU callbacks beyond which
>                         batch limiting is disabled.
>  
>         rcutree.qlowmark= [KNL]
>                         Set threshold of queued RCU callbacks below which
>                         batch limiting is re-enabled.
>  
>         rcutree.qovld= [KNL]
>                         Set threshold of queued RCU callbacks beyond which
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index fcf2b4aa3441..62ede401420f 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -512,20 +512,21 @@ do {                                                              \
>         local_irq_save(flags);                                  \
>         if (rcu_segcblist_is_offloaded(&(rdp)->cblist)) \
>                 raw_spin_lock(&(rdp)->nocb_lock);               \
>  } while (0)
>  #else /* #ifdef CONFIG_RCU_NOCB_CPU */
>  #define rcu_nocb_lock_irqsave(rdp, flags) local_irq_save(flags)
>  #endif /* #else #ifdef CONFIG_RCU_NOCB_CPU */
>  
>  static void rcu_bind_gp_kthread(void);
>  static bool rcu_nohz_full_cpu(void);
> +static bool rcu_on_patience_delay(void);

I don't think we need an access function, but will check below.

>  /* Forward declarations for tree_stall.h */
>  static void record_gp_stall_check_time(void);
>  static void rcu_iw_handler(struct irq_work *iwp);
>  static void check_cpu_stall(struct rcu_data *rdp);
>  static void rcu_check_gp_start_stall(struct rcu_node *rnp, struct rcu_data *rdp,
>                                      const unsigned long gpssdelay);
>  
>  /* Forward declarations for tree_exp.h. */
>  static void sync_rcu_do_polled_gp(struct work_struct *wp);
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 340bbefe5f65..639243b0410f 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -5,20 +5,21 @@
>   * or preemptible semantics.
>   *
>   * Copyright Red Hat, 2009
>   * Copyright IBM Corporation, 2009
>   *
>   * Author: Ingo Molnar <mingo@elte.hu>
>   *        Paul E. McKenney <paulmck@linux.ibm.com>
>   */
>  
>  #include "../locking/rtmutex_common.h"
> +#include <linux/jiffies.h>

This is already pulled in by the enclosing tree.c file, so it should not
be necessary to include it again.  (Or did you get a build failure when
leaving this out?)

>  static bool rcu_rdp_is_offloaded(struct rcu_data *rdp)
>  {
>         /*
>          * In order to read the offloaded state of an rdp in a safe
>          * and stable way and prevent from its value to be changed
>          * under us, we must either hold the barrier mutex, the cpu
>          * hotplug lock (read or write) or the nocb lock. Local
>          * non-preemptible reads are also safe. NOCB kthreads and
>          * timers have their own means of synchronization against the
> @@ -86,20 +87,33 @@ static void __init rcu_bootup_announce_oddness(void)
>         if (rcu_kick_kthreads)
>                 pr_info("\tKick kthreads if too-long grace period.\n");
>         if (IS_ENABLED(CONFIG_DEBUG_OBJECTS_RCU_HEAD))
>                 pr_info("\tRCU callback double-/use-after-free debug is enabled.\n");
>         if (gp_preinit_delay)
>                 pr_info("\tRCU debug GP pre-init slowdown %d jiffies.\n", gp_preinit_delay);
>         if (gp_init_delay)
>                 pr_info("\tRCU debug GP init slowdown %d jiffies.\n", gp_init_delay);
>         if (gp_cleanup_delay)
>                 pr_info("\tRCU debug GP cleanup slowdown %d jiffies.\n", gp_cleanup_delay);
> +       if (nocb_patience_delay < 0) {
> +               pr_info("\tRCU NOCB CPU patience negative (%d), resetting to zero.\n",
> +                       nocb_patience_delay);
> +               nocb_patience_delay = 0;
> +       } else if (nocb_patience_delay > 5 * MSEC_PER_SEC) {
> +               pr_info("\tRCU NOCB CPU patience too large (%d), resetting to %ld.\n",
> +                       nocb_patience_delay, 5 * MSEC_PER_SEC);
> +               nocb_patience_delay = msecs_to_jiffies(5 * MSEC_PER_SEC);
> +       } else if (nocb_patience_delay) {
> +               nocb_patience_delay = msecs_to_jiffies(nocb_patience_delay);
> +               pr_info("\tRCU NOCB CPU patience set to %d milliseconds.\n",
> +                       jiffies_to_msecs(nocb_patience_delay);
> +       }

I just did this here at the end:

	nocb_patience_delay_jiffies = msecs_to_jiffies(nocb_patience_delay);

Ah, you are wanting to print out the milliseconds after the rounding
to jiffies.

I am going to hold off on that for the moment, but I hear your request
and I have not yet said "no".  ;-)

>         if (!use_softirq)
>                 pr_info("\tRCU_SOFTIRQ processing moved to rcuc kthreads.\n");
>         if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG))
>                 pr_info("\tRCU debug extended QS entry/exit.\n");
>         rcupdate_announce_bootup_oddness();
>  }
>  
>  #ifdef CONFIG_PREEMPT_RCU
>  
>  static void rcu_report_exp_rnp(struct rcu_node *rnp, bool wake);
> @@ -1260,10 +1274,29 @@ static bool rcu_nohz_full_cpu(void)
>  
>  /*
>   * Bind the RCU grace-period kthreads to the housekeeping CPU.
>   */
>  static void rcu_bind_gp_kthread(void)
>  {
>         if (!tick_nohz_full_enabled())
>                 return;
>         housekeeping_affine(current, HK_TYPE_RCU);
>  }
> +
> +/*
> + * Is this CPU a NO_HZ_FULL CPU that should ignore RCU if the time since the
> + * start of current grace period is smaller than nocb_patience_delay ?
> + *
> + * This code relies on the fact that all NO_HZ_FULL CPUs are also
> + * RCU_NOCB_CPU CPUs.
> + */
> +static bool rcu_on_patience_delay(void)
> +{
> +#ifdef CONFIG_NO_HZ_FULL

You lost me on this one.  Why do we need the #ifdef instead of
IS_ENABLED()?  Also, please note that rcu_nohz_full_cpu() is already a
compile-time @false in CONFIG_NO_HZ_FULL=n kernels.

> +       if (!nocb_patience_delay)
> +               return false;

We get this automatically with the comparison below, right?  If so, we
are not gaining much by creating the helper function.  Or am I missing
some trick here?

							Thanx, Paul

> +       if (time_before(jiffies, READ_ONCE(rcu_state.gp_start) + nocb_patience_delay))
> +               return true;
> +#endif /* #ifdef CONFIG_NO_HZ_FULL */
> +       return false;
> +}
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 7560e204198b..7a2d94370ab4 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -169,20 +169,22 @@ static int kthread_prio = IS_ENABLED(CONFIG_RCU_BOOST) ? 1 : 0;
>  module_param(kthread_prio, int, 0444);
>  
>  /* Delay in jiffies for grace-period initialization delays, debug only. */
>  
>  static int gp_preinit_delay;
>  module_param(gp_preinit_delay, int, 0444);
>  static int gp_init_delay;
>  module_param(gp_init_delay, int, 0444);
>  static int gp_cleanup_delay;
>  module_param(gp_cleanup_delay, int, 0444);
> +static int nocb_patience_delay;
> +module_param(nocb_patience_delay, int, 0444);
>  
>  // Add delay to rcu_read_unlock() for strict grace periods.
>  static int rcu_unlock_delay;
>  #ifdef CONFIG_RCU_STRICT_GRACE_PERIOD
>  module_param(rcu_unlock_delay, int, 0444);
>  #endif
>  
>  /*
>   * This rcu parameter is runtime-read-only. It reflects
>   * a minimum allowed number of objects which can be cached
> @@ -4340,25 +4342,27 @@ static int rcu_pending(int user)
>         lockdep_assert_irqs_disabled();
>  
>         /* Check for CPU stalls, if enabled. */
>         check_cpu_stall(rdp);
>  
>         /* Does this CPU need a deferred NOCB wakeup? */
>         if (rcu_nocb_need_deferred_wakeup(rdp, RCU_NOCB_WAKE))
>                 return 1;
>  
>         /* Is this a nohz_full CPU in userspace or idle?  (Ignore RCU if so.) */
> -       if ((user || rcu_is_cpu_rrupt_from_idle()) && rcu_nohz_full_cpu())
> +       gp_in_progress = rcu_gp_in_progress();
> +       if ((user || rcu_is_cpu_rrupt_from_idle() ||
> +            (gp_in_progress && rcu_on_patience_delay())) &&
> +           rcu_nohz_full_cpu())
>                 return 0;
>  
>         /* Is the RCU core waiting for a quiescent state from this CPU? */
> -       gp_in_progress = rcu_gp_in_progress();
>         if (rdp->core_needs_qs && !rdp->cpu_no_qs.b.norm && gp_in_progress)
>                 return 1;
>  
>         /* Does this CPU have callbacks ready to invoke? */
>         if (!rcu_rdp_is_offloaded(rdp) &&
>             rcu_segcblist_ready_cbs(&rdp->cblist))
>                 return 1;
>  
>         /* Has RCU gone idle with this CPU needing another grace period? */
>         if (!gp_in_progress && rcu_segcblist_is_enabled(&rdp->cblist) &&
> 
> 
> 

  reply	other threads:[~2024-05-09 23:45 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 17:19 [RFC PATCH v1 0/2] Avoid rcu_core() if CPU just left guest vcpu Leonardo Bras
2024-03-28 17:19 ` [RFC PATCH v1 1/2] kvm: Implement guest_exit_last_time() Leonardo Bras
2024-03-28 17:19 ` [RFC PATCH v1 2/2] rcu: Ignore RCU in nohz_full cpus if it was running a guest recently Leonardo Bras
2024-04-01 15:52   ` Paul E. McKenney
2024-04-01 20:21 ` [RFC PATCH v1 0/2] Avoid rcu_core() if CPU just left guest vcpu Sean Christopherson
2024-04-05 13:45   ` Marcelo Tosatti
2024-04-05 14:42     ` Sean Christopherson
2024-04-06  0:03       ` Paul E. McKenney
2024-04-08 17:16         ` Sean Christopherson
2024-04-08 18:42           ` Paul E. McKenney
2024-04-08 20:06             ` Sean Christopherson
2024-04-08 21:02               ` Paul E. McKenney
2024-04-08 21:56                 ` Sean Christopherson
2024-04-08 22:35                   ` Paul E. McKenney
2024-04-08 23:06                     ` Sean Christopherson
2024-04-08 23:20                       ` Paul E. McKenney
2024-04-10  2:39           ` Marcelo Tosatti
2024-04-15 19:47           ` Marcelo Tosatti
2024-04-15 21:29             ` Sean Christopherson
2024-04-16 12:36               ` Marcelo Tosatti
2024-04-16 14:07                 ` Sean Christopherson
2024-04-17 16:14                   ` Marcelo Tosatti
2024-04-17 17:22                     ` Sean Christopherson
2024-05-03 20:44                       ` Leonardo Bras
2024-05-06 18:47                         ` Marcelo Tosatti
2024-05-07 18:05                           ` Sean Christopherson
2024-05-07 22:36                             ` Leonardo Bras
2024-05-03 18:42   ` Leonardo Bras
2024-05-03 19:09     ` Leonardo Bras
2024-05-03 21:29     ` Sean Christopherson
2024-05-03 22:00       ` Leonardo Bras
2024-05-03 22:00       ` Paul E. McKenney
2024-05-07 17:55         ` Sean Christopherson
2024-05-07 19:15           ` Paul E. McKenney
2024-05-07 21:00             ` Sean Christopherson
2024-05-07 21:37               ` Paul E. McKenney
2024-05-07 23:47                 ` Sean Christopherson
2024-05-08  0:08                   ` Sean Christopherson
2024-05-08  2:51                     ` Leonardo Bras
2024-05-08  3:22                       ` Paul E. McKenney
2024-05-08  6:19                         ` Leonardo Bras
2024-05-08 14:01                           ` Sean Christopherson
2024-05-09  3:32                             ` Paul E. McKenney
2024-05-09  8:16                               ` Leonardo Bras
2024-05-09 10:14                                 ` Leonardo Bras
2024-05-09 23:45                                   ` Paul E. McKenney [this message]
2024-05-10 16:06                                     ` Leonardo Bras
2024-05-10 16:21                                       ` Paul E. McKenney
2024-05-10 17:12                                         ` Leonardo Bras
2024-05-10 17:41                                           ` Paul E. McKenney
2024-05-10 19:50                                             ` Leonardo Bras
2024-05-10 21:15                                               ` Leonardo Bras
2024-05-10 21:38                                                 ` Paul E. McKenney
2024-05-09 22:41                                 ` Paul E. McKenney
2024-05-09 23:07                                   ` Leonardo Bras Soares Passos
2024-05-11  2:08                             ` Leonardo Bras
2024-05-08  3:20                     ` Paul E. McKenney
2024-05-08  4:04                       ` Paul E. McKenney
2024-05-08 14:36                         ` Paul E. McKenney
2024-05-08 15:35                       ` Sean Christopherson

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=09a8f4f6-a692-4586-bb68-b0a524b7a5d8@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=boqun.feng@gmail.com \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kvm@vger.kernel.org \
    --cc=leobras@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qiang.zhang1211@gmail.com \
    --cc=quic_neeraju@quicinc.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).