Re: [Xen-devel] Fast inter-VM signaling using monitor/mwait

[Michael Abd-El-Malek <mabdelmalek@xxxxxxx>]

On May 6, 2009, at 11:05 AM, Keir Fraser wrote:

> On 06/05/2009 15:38, "Michael Abd-El-Malek" <mabdelmalek@xxxxxxx>  
> wrote:
> > > In Xen actual vcpu scheduling happens at the point before resuming
> > > back to VM, instead of in timer interrupt ISR. So as long as your
> > > monitor/mwait loop in hypercall doesn't exit before update is
> > > observed,
> > > scheduling won't happen.
> > I'm not an expert on Xen scheduling, so please correct my following
> > understanding.  For the credit scheduler, csched_tick sets the next
> > timer interrupt.  So after the mwait hypercall executes the mwait
> > instruction and is waiting for a memory write, I observe the timer
> > interrupt eventually causing the mwait instruction to return.  The
> > mwait hypercall can then run the scheduler.
> The issue is, what if another VM's VCPUs are runnable? Xen should  
> prefer to
> run those rather than pause the CPU on an MWAIT, right? But if it  
> does that
> it will lose the memory-access wakeup property of the MWAIT and cannot
> schedule the 'MWAIT'ing VM back in promptly when the relevant memory  
> access
> occurs. I don't see that MWAIT can used effectively in a guest idle  
> loop
> unless you are happy to bin the work-conserving property of the Xen
> scheduler (e.g., by dedicating a physical CPU to the VM).
I see the issue, thanks for explaining this.  Yes, I have dedicated a  
physical CPU to my VM, which does throw away the work-conserving  
property.  As a solution, what if the source VM continues to use the  
"send event" hypercall to signal the destination VM, but we modify the  
"send event" hypercall as follows.  If the destination VM is currently  
executing _and_ is blocked in an mwait hypercall, then we simply write  
to its monitored memory address.  Otherwise, we fall back to the  
existing event channel mechanism.
How does that sound?

Thanks,
Mike

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel