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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2017-02-21 at 13:46 +0000, George Dunlap wrote:
>
> A.  Don't trap guest WFI at all -- allow it to 'halt' in
> moderate-power-but-ready-for-interrupt mode.
> 
> [..]
>
> 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").
> 
Are you also referring to the case when there are less vCPUs around
than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a
pCPU)? If yes, I agree that we're probably fine, but we have to check
and enforce all this to be the case.

If no, think at a situation where there is 1 vCPU running on a pCPU and
3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a
shared among some pCPUs Credit2 runqueue). If the running vCPU goes
idle, let's say with WFI, we _don't_ want the pCPU to enter neither
moderate nor deep sleep, we want to pick up the first of the 3 other
vCPUs that are waiting in the runqueue.

This is what I mean when I say "breaks scheduling". :-)

Oh, actually, if --which I only now realize may be what you are
referring to, since you're talking about "guest burning its credits"--
you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when
the scheduler runs again for whatever reason), you charge to it for all
the time the the pCPU was actually idle/sleeping, well, that may
actually  not break scheduling, or cause disruption to the service of
other vCPUs.... But indeed I'd consider it rather counter intuitive a
behavior.

In fact, it'd mean that the guest has issued WFI because he wanted to
sleep and we do put it to sleep. But when it wakes up, we treat it like
it had busy waited.

What would be the benefit of this? That we don't context switch (either
to idle or to someone else)?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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