lkml.org 
[lkml]   [2011]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RCU treating guest mode just like it does user-mode execution
On Thu, Aug 18, 2011 at 12:50:15AM +0300, Gleb Natapov wrote:
> 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.

Good to know, thank you!

> > 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.

Might be that the current state is optimal. That would be a good thing.

But if a CPU stays in guest mode for (say) 30 seconds, it will have
called schedule() every jiffy in the meantime? In other words, if
a CPU stays in guest mode for a long time, how does RCU know that
this CPU is in an extended quiescent state?

Thanx, Paul


\
 
 \ /
  Last update: 2011-08-18 00:07    [W:0.094 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site