public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Bras <leobras@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Leonardo Bras <leobras@redhat.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Leonardo Bras <leobras.c@gmail.com>,
	Sean Christopherson <seanjc@google.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.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: Fri, 12 Jul 2024 17:02:30 -0300	[thread overview]
Message-ID: <ZpGL1rEHNild9CG5@LeoBras> (raw)
In-Reply-To: <f06ef91d-7f8c-4f69-8535-fee372766a7f@redhat.com>

On Fri, Jul 12, 2024 at 05:57:10PM +0200, Paolo Bonzini wrote:
> On 7/11/24 01:18, Leonardo Bras wrote:
> > What are your thoughts on above results?
> > Anything you would suggest changing?
> 

Hello Paolo, thanks for the feedback!

> Can you run the test with a conditional on "!tick_nohz_full_cpu(vcpu->cpu)"?
> 
> If your hunch is correct that nohz-full CPUs already avoid invoke_rcu_core()
> you might get the best of both worlds.
> 
> tick_nohz_full_cpu() is very fast when there is no nohz-full CPU, because
> then it shortcuts on context_tracking_enabled() (which is just a static
> key).

But that would mean not noting an RCU quiescent state in guest_exit of 
nohz_full cpus, right?

The original issue we were dealing was having invoke_rcu_core() running on 
nohz_full cpus, and messing up the latency of RT workloads inside the VM.

While most of the invoke_rcu_core() get ignored by the nohz_full rule, 
there are some scenarios in which it the vcpu thread may take more than 1s 
between a guest_entry and the next one (VM busy), and those which did 
not get ignored have caused latency peaks in our tests.

The main idea of this patch is to note RCU quiescent states on guest_exit 
at nohz_full cpus (and use rcu.patience) to avoid running invoke_rcu_core()
between a guest_exit and the next guest_entry if it takes less than 
rcu.patience miliseconds between exit and entry, and thus avoiding the 
latency increase.

What I tried to prove above is that it also improves non-Isolated cores as 
well, since rcu_core will not be running as often, saving cpu cycles that 
can be used by the VM.


What are your thoughts on that?

Thanks!
Leo


  reply	other threads:[~2024-07-12 20:02 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
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 [this message]
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=ZpGL1rEHNild9CG5@LeoBras \
    --to=leobras@redhat.com \
    --cc=frederic@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=leobras.c@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox