[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.