Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Sun, 19 Feb 2017, Julien Grall wrote:
> Hi Stefano,
> 
> I have CCed another ARM person who has more knowledge than me on
> scheduling/power.
> 
> On 02/17/2017 10:50 PM, Stefano Stabellini wrote:
> > CC'ing xen-devel, I forgot on the original patch
> > 
> > On Fri, 17 Feb 2017, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 02/16/2017 11:04 PM, Stefano Stabellini wrote:
> > > > Introduce new Xen command line parameter called "vwfi", which stands for
> > > > virtual wfi. The default is "sleep": on guest wfi, Xen calls vcpu_block
> > > > on the guest vcpu. The behavior can be changed setting vwfi to "idle",
> > > > in that case Xen calls vcpu_yield.
> > > > 
> > > > The result is strong reduction in irq latency (8050ns -> 3500ns) at the
> > > > cost of idle_loop being called less often, leading to higher power
> > > > consumption.
> > > 
> > > Please explain in which context this will be beneficial. My gut feeling is
> > > only will make performance worst if a multiple vCPU of the same guest is
> > > running on vCPU
> > 
> > I am not a scheduler expert, but I don't think so. Let me explain the
> > difference:
> > 
> > - vcpu_block blocks a vcpu until an event occurs, for example until it
> >   receives an interrupt
> > 
> > - vcpu_yield stops the vcpu from running until the next scheduler slot
> > 
> > In both cases the vcpus is not run until the next slot, so I don't think
> > it should make the performance worse in multi-vcpus scenarios. But I can
> > do some tests to double check.
> 
> You still haven't explained how you came up with those number? My guess is 1
> vCPU per pCPU but it is not clear from the commit message.

It's the same setup I used for
alpine.DEB.2.10.1702091603240.20549@sstabellini-ThinkPad-X260, I'll add
more info to the commit message.


> > > I don't think this is acceptable even to get a better interrupt latency.
> > > Some
> > > workload will care about interrupt latency and power.
> > > 
> > > I think a better approach would be to check whether the scheduler has
> > > another
> > > vCPU to run. If not wait for an interrupt in the trap.
> > > 
> > > This would save the context switch to the idle vCPU if we are still on the
> > > time slice of the vCPU.
> > 
> > From my limited understanding of how schedulers work, I think this
> > cannot work reliably. It is the scheduler that needs to tell the
> > arch-specific code to put a pcpu to sleep, not the other way around. I
> > would appreciate if Dario could confirm this though.
> 
> If my understanding is correct, your workload is 1 vCPU per pCPU. So why do
> you need to trap WFI/WFE in this case?
> 
> Would not it be easier to let the guest using them directly?

This is a good question, I have already answered: I think it would break
the scheduler. Dario confirmed it in his reply
(1487382463.6732.146.camel@xxxxxxxxxx).

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel