From: "Paul E. McKenney" <paulmck@kernel.org>
To: Leonardo Bras <leobras@redhat.com>
Cc: 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 2/2] rcu: Ignore RCU in nohz_full cpus if it was running a guest recently
Date: Mon, 1 Apr 2024 08:52:22 -0700 [thread overview]
Message-ID: <b616a57b-56bf-4cdd-abc3-f2064b14abf6@paulmck-laptop> (raw)
In-Reply-To: <20240328171949.743211-3-leobras@redhat.com>
On Thu, Mar 28, 2024 at 02:19:47PM -0300, Leonardo Bras wrote:
> In current code, we can ignore the RCU request on a nohz_full cpu for up to
> a second if it has interrupted idle or userspace tasks, since those are
> quiescent states, and will probably return to it soon thus not requiring
> to run a softirq or a rcuc thread.
>
> Running a guest is also considered to be a quiescent state, and will
> follow the same logic, so it makes sense to also ignore the RCU request in
> this case.
>
> This solves a latency issue of a latency-sensitive workload running on a
> guest pinned in nohz_full cpu: if the guest goes out for any reason, and a
> synchronize_rcu() is requested between guest exit and a timer interrupt,
> then invoke_rcu_core() is called, and introduce latency due to either a
> softirq, or a reschedule to run rcuc, if the host is a PREEMPT_RT kernel.
>
> Suggested-by: Marcelo Tosatti <mtosatti@redhat.com>
> Signed-off-by: Leonardo Bras <leobras@redhat.com>
Looks plausible to me!
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Or let me know if you would rather these go through -rcu.
Thanx, Paul
> ---
> kernel/rcu/tree_plugin.h | 14 ++++++++++++++
> kernel/rcu/tree.c | 4 +++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 36a8b5dbf5b5..16f3cf2e15df 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/kvm_host.h"
>
> 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
> @@ -1260,10 +1261,23 @@ 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);
> }
> +
> +/*
> + * true if for this cpu guest exit is at most over a second ago,
> + * false otherwise
> + */
> +static bool rcu_recent_guest_exit(void)
> +{
> +#ifdef CONFIG_KVM
> + return time_before(jiffies, guest_exit_last_time() + HZ);
> +#else
> + return false;
> +#endif
> +}
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index d9642dd06c25..e5ce00bf1898 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -148,20 +148,21 @@ static void rcu_report_qs_rnp(unsigned long mask, struct rcu_node *rnp,
> static struct task_struct *rcu_boost_task(struct rcu_node *rnp);
> static void invoke_rcu_core(void);
> static void rcu_report_exp_rdp(struct rcu_data *rdp);
> static void sync_sched_exp_online_cleanup(int cpu);
> static void check_cb_ovld_locked(struct rcu_data *rdp, struct rcu_node *rnp);
> static bool rcu_rdp_is_offloaded(struct rcu_data *rdp);
> static bool rcu_rdp_cpu_online(struct rcu_data *rdp);
> static bool rcu_init_invoked(void);
> static void rcu_cleanup_dead_rnp(struct rcu_node *rnp_leaf);
> static void rcu_init_new_rnp(struct rcu_node *rnp_leaf);
> +static bool rcu_recent_guest_exit(void);
>
> /*
> * rcuc/rcub/rcuop kthread realtime priority. The "rcuop"
> * real-time priority(enabling/disabling) is controlled by
> * the extra CONFIG_RCU_NOCB_CPU_CB_BOOST configuration.
> */
> 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. */
> @@ -3931,21 +3932,22 @@ 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())
> + if ((user || rcu_is_cpu_rrupt_from_idle() || rcu_recent_guest_exit()) &&
> + 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))
> --
> 2.44.0
>
next prev parent reply other threads:[~2024-04-01 15:52 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 [this message]
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
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=b616a57b-56bf-4cdd-abc3-f2064b14abf6@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 \
/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).