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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 21 Feb 2017, Julien Grall wrote:
> Hi George,
> 
> On 21/02/17 13:46, George Dunlap wrote:
> > I think our options look like:
> 
> Thank you for the summary of the options!
> 
> > 
> > A.  Don't trap guest WFI at all -- allow it to 'halt' in
> > moderate-power-but-ready-for-interrupt mode.
> > 
> > B. Trap guest WFI and block normally.
> > 
> > C. Trap guest WFI and poll instead of idling.
> > 
> > D. Trap guest WFI and take that as a hint to "idle" in a non-deep sleep
> > state (perhaps, for instance, using the WFI instruction).
> > 
> > A is safe because the scheduler should already have set a timer to break
> > out of it if necessary.  The only potential issue here is that the guest
> > is burning its credits, meaning that other vcpus with something
> > potentially useful to do aren't being allowed to run; and then later
> > when this vcpu has something useful to do it may be prevented from
> > running because of low credits.  (This may be what Dario means when he
> > says it "breaks scheduling").
> > 
> > B, C, and D have the advantage that the guest will not be charged for
> > credits, and other useful work can be done if it's possible.
> > 
> > B and C have the disadvantage that the effect will be significantly
> > different under Xen than on real hardware: B will mean it will go into a
> > deep sleep state (and thus not be as responsive as on real hardare); C
> > has the disadvantage that there won't be any significant power savings.
> 
> I'd like to correct one misunderstanding here. Today the idle_loop on ARM is
> doing a WFI. This is not a deep-sleep state, it is fairly quite quick to come
> back. What really cost if the context switch of the state of the vCPU during
> blocking.
> 
> So I think B and D are the same. Or did you expect D to not switch to the idle
> vCPU?

I think that B and D are the same only in the scenario where each vcpu
is pinned to a different pcpu. However, we cannot automatically
configure this scenario and we cannot detect it when it happens.

Discussions on how to make this specific scenario better are fruitless
until we can detect and configure Xen for it. Your suggestion to do a
real wfi when the guest issues a virtual wfi is a good improvement at
that point in time. Now, we cannot do it, because we don't know when it
happens.

If Dario and George come up with a way to detect it or configure it, I
volunteer to write the wfi patch for Xen ARM. Until then, we can only
decide if it is worth having a vwfi option, either system wide or per
domain, to change vwfi behavior from sleep to poll. When we have a way
to configure 1vcpu=1pcpu, we'll be able to add one more option, for
example vwfi=passthrough, that will allow a vcpu to perform a physical
wfi, leading to optimal power saving and wake up times.

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