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

[Julien Grall <julien.grall@xxxxxxx>]

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