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

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



Hi Stefano,

On 21/02/17 18:03, Stefano Stabellini wrote:
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.

Again, there is no deep sleep state supported on Xen today. The idle loop on Xen is a simple WFI. So there is *no* difference between B and D no matter the configuration, both option trap WFI and block the vCPU.


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.

Please read my answer to Dario (<14575011-0042-8940-c19f-2482136ff91c@xxxxxxxxxxxx>) regarding why an baremetal app will use WFI and what are the expectations of WFI.

I will summarize my e-mail with that:

My shiny baremetal app is running nicely without virtualization, good power usage, good interrupt latency. Now, I want to use virtualization to abstract the hardware, it will have a small overhead impact because of virtualization but it is ok. Now, you are telling me that if I want good interrupt latency, I would have to give up on power. I would likely give up on using virtualization in this case, better to adapt my app to the newer hardware. Do you really expect user to make another decision?

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®.