public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, avi@redhat.com,
	mtosatti@redhat.com, kvm@vger.kernel.org
Subject: Re: RCU treating guest mode just like it does user-mode execution
Date: Thu, 18 Aug 2011 00:50:15 +0300	[thread overview]
Message-ID: <20110817215015.GA6423@redhat.com> (raw)
In-Reply-To: <20110817204327.GA10633@linux.vnet.ibm.com>

On Wed, Aug 17, 2011 at 01:43:27PM -0700, Paul E. McKenney wrote:
> Hello, Gleb,
> 
> I was looking at KVM's call to rcu_virt_note_context_switch()
> in kvm_guest_enter(), and noting the comment talking about treating
> guest mode like user-mode execution is.  One difference between RCU's
> treatment of KVM guest execution and user-mode execution is that RCU
> notes a context switch only at the beginning of KVM guest execution,
> but notes user-mode execution at every scheduling-clock interrupt.
> 
> Does it make sense to also note KVM guest execution on each
> scheduling-clock interrupt?  One reason it might not make sense is
> if interrupts from KVM guest execution appear to rcu_check_callbacks()
> as interrupts from user-mode execution.  (Do they?  Given that people
> are reporting RCU CPU stall warnings in virtualized environments, I
> am beginning to suspect that the answer is "no".)
> 
The answer is "no" because any interrupt kicks cpu out of a guest mode, so
it appears to be in the kernel for RCU. Do people still reporting RCU
stalls even with the my patch?

> If KVM guest execution does not appear as user-mode execution to
> rcu_check_callback(), I would consider doing the following:
> 
> 1.	Rename rcu_virt_note_context_switch() to something like
> 	rcu_guest_execution_start().
> 
> 2.	Place a call to a new rcu_guest_execution_end() in
> 	kvm_guest_exit().
> 
> 3.	Make rcu_guest_execution_start() and rcu_guest_execution_end()
> 	set and clear a new per-CPU variable.
There is such variable already: current->flags & PF_VCPU.

> 
> 4.	Make rcu_check_callbacks() check this per-CPU variable in
> 	much the same way that it currently checks its "user"
> 	argument, aside from needing to check that the CPU is
> 	not in an interrupt handler or some such.
> 
> Of course, some thought is required to make sure that the checks for
> executing in an interrupt handler actually cover all of the needed
> situations, but so it goes!
> 
> Thoughts?
I wonder why it will be better than current situation. After cpu leaves
a guest mode there are only three options. It will either go to
userspace, execute schedule or go back to guest mode. At all those cases
RCU should note quiescent state.

--
			Gleb.

  reply	other threads:[~2011-08-17 21:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-17 20:43 RCU treating guest mode just like it does user-mode execution Paul E. McKenney
2011-08-17 21:50 ` Gleb Natapov [this message]
2011-08-17 22:05   ` Paul E. McKenney
2011-08-17 23:55     ` Gleb Natapov
2011-08-18  0:25       ` Paul E. McKenney
2011-08-18  0:28         ` Avi Kivity
2011-08-18  0:44           ` Paul E. McKenney
2011-08-18  0:53             ` Avi Kivity
2011-08-18  0:44         ` Gleb Natapov

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=20110817215015.GA6423@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=paulmck@linux.vnet.ibm.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