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

[Julien Grall <julien.grall@xxxxxxx>]

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?
Note, it is possible to implement more deep-sleep state on ARM either 
via PSCI or platform specific code.
> Having the ability for an administrator to choose between A and D seems
> like it would be the most useful.
Cheers,

--
Julien Grall

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