From: Marcelo Tosatti <mtosatti@redhat.com>
To: Leonardo Bras <leobras@redhat.com>
Cc: Frederic Weisbecker <frederic@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] kvm: Note an RCU quiescent state on guest exit
Date: Mon, 13 May 2024 16:14:03 -0300 [thread overview]
Message-ID: <ZkJme7kRGGNdxwnb@tpad> (raw)
In-Reply-To: <ZkGFmISfnrKNrUgj@LeoBras>
On Mon, May 13, 2024 at 12:14:32AM -0300, Leonardo Bras wrote:
> On Sun, May 12, 2024 at 06:44:23PM -0300, Marcelo Tosatti wrote:
> > On Fri, May 10, 2024 at 11:05:56PM -0300, Leonardo Bras wrote:
> > > As of today, KVM notes a quiescent state only in guest entry, which is good
> > > as it avoids the guest being interrupted for current RCU operations.
> > >
> > > While the guest vcpu runs, it can be interrupted by a timer IRQ that will
> > > check for any RCU operations waiting for this CPU. In case there are any of
> > > such, it invokes rcu_core() in order to sched-out the current thread and
> > > note a quiescent state.
> > >
> > > This occasional schedule work will introduce tens of microsseconds of
> > > latency, which is really bad for vcpus running latency-sensitive
> > > applications, such as real-time workloads.
> > >
> > > So, note a quiescent state in guest exit, so the interrupted guests is able
> > > to deal with any pending RCU operations before being required to invoke
> > > rcu_core(), and thus avoid the overhead of related scheduler work.
> >
> > This does not properly fix the current problem, as RCU work might be
> > scheduled after the VM exit, followed by a timer interrupt.
> >
> > Correct?
>
> Correct, for this case, check the note below:
>
> >
> > >
> > > Signed-off-by: Leonardo Bras <leobras@redhat.com>
> > > ---
> > >
> > > ps: A patch fixing this same issue was discussed in this thread:
> > > https://lore.kernel.org/all/20240328171949.743211-1-leobras@redhat.com/
> > >
> > > Also, this can be paired with a new RCU option (rcutree.nocb_patience_delay)
> > > to avoid having invoke_rcu() being called on grace-periods starting between
> > > guest exit and the timer IRQ. This RCU option is being discussed in a
> > > sub-thread of this message:
> > > https://lore.kernel.org/all/5fd66909-1250-4a91-aa71-93cb36ed4ad5@paulmck-laptop/
>
> ^ This one above.
> The idea is to use this rcutree.nocb_patience_delay=N :
> a new option we added on RCU that allow us to avoid invoking rcu_core() if
> the grace_period < N miliseconds. This only works on nohz_full cpus.
>
> So with both the current patch and the one in above link, we have the same
> effect as we previously had with last_guest_exit, with a cherry on top: we
> can avoid rcu_core() getting called in situations where a grace period just
> started after going into kernel code, and a timer interrupt happened before
> it can report quiescent state again.
>
> For our nohz_full vcpu thread scenario, we have:
>
> - guest_exit note a quiescent state
> - let's say we start a grace period in the next cycle
> - If timer interrupts, it requires the grace period to be older than N
> miliseconds
> - If we configure a proper value for patience, it will never reach the
> end of patience before going guest_entry, and thus noting a quiescent
> state
>
> What do you think?
I don't fully understand all of the RCU details, but since RCU quiescent
state marking happens in IRQ disabled section, there is no chance for a
timer interrupt to conflict with the marking of quiescent state.
So seem to make sense to me.
next prev parent reply other threads:[~2024-05-13 19:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-11 2:05 [RFC PATCH 1/1] kvm: Note an RCU quiescent state on guest exit Leonardo Bras
2024-05-11 2:11 ` Leonardo Bras
2024-05-11 14:55 ` Paul E. McKenney
2024-05-11 20:31 ` Leonardo Bras
2024-05-12 21:44 ` Marcelo Tosatti
2024-05-13 1:06 ` Marcelo Tosatti
2024-05-13 3:14 ` Leonardo Bras
2024-05-13 19:14 ` Marcelo Tosatti [this message]
2024-05-13 19:40 ` Sean Christopherson
2024-05-13 21:47 ` Leonardo Bras Soares Passos
2024-05-14 22:54 ` Paul E. McKenney
2024-05-15 4:45 ` Leonardo Bras
2024-05-15 14:57 ` Paul E. McKenney
2024-06-20 7:03 ` Leonardo Bras
2024-06-20 17:26 ` Paul E. McKenney
2024-06-25 2:31 ` Leonardo Bras
2024-06-25 2:34 ` Leonardo Bras
2024-07-10 23:18 ` Leonardo Bras
2024-07-12 15:57 ` Paolo Bonzini
2024-07-12 20:02 ` Leonardo Bras
2024-07-29 11:28 ` Leonardo Bras Soares Passos
2024-08-27 19:50 ` Leonardo Bras Soares Passos
2024-09-03 18:07 ` 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=ZkJme7kRGGNdxwnb@tpad \
--to=mtosatti@redhat.com \
--cc=frederic@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--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 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.