Re: [v7 0/8] Reduce cross CPU IPI interference

[Frederic Weisbecker]

On Sun, Feb 05, 2012 at 08:59:27AM -0800, Paul E. McKenney wrote:
> On Sun, Feb 05, 2012 at 02:16:17PM +0200, Avi Kivity wrote:
> > On 02/02/2012 07:51 PM, Paul E. McKenney wrote:
> > > On Thu, Feb 02, 2012 at 07:23:39PM +0200, Avi Kivity wrote:
> > > > On 02/02/2012 07:01 PM, Paul E. McKenney wrote:
> > > > > > 
> > > > > > It's not called (since the cpu is not idle).  Instead we call
> > > > > > rcu_virt_note_context_switch().
> > > > >
> > > > > Frederic's work checks to see if there is only one runnable user task
> > > > > on a given CPU.  If there is only one, then the scheduling-clock interrupt
> > > > > is turned off for that CPU, and RCU is told to ignore it while it is
> > > > > executing in user space.  Not sure whether this covers KVM guests.
> > > > 
> > > > Conceptually it's the same.  Maybe it needs adjustments, since kvm
> > > > enters a guest in a different way than the kernel exits to userspace.
> > > > 
> > > > > In any case, this is not yet in mainline.
> > > > 
> > > > Let me know when it's in, and I'll have a look.
> > >
> > > Could you please touch base with Frederic Weisbecker to make sure that
> > > what he is doing works for you?
> > 
> > Looks like there are new rcu_user_enter() and rcu_user_exit() APIs which
> > we can use.  Hopefully they subsume rcu_virt_note_context_switch() so we
> > only need one set of APIs.
> 
> Now that you mention it, that is a good goal.  However, it requires
> coordination with Frederic's code as well, so some investigation
> is required.  Bad things happen if you tell RCU you are idle when you
> really are not and vice versa!
> 
> 							Thanx, Paul
> 

Right. Avi I need to know more about what you need. rcu_virt_note_context_switch()
notes a quiescent state while rcu_user_enter() shuts down RCU (it's in fact the same
thing than rcu_idle_enter() minus the is_idle_cpu() checks).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/