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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 21 Feb 2017, Dario Faggioli wrote:
> 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". :-)

That's right, I cannot see how this can be made to work correctly.


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

How can this be safe? There could be no interrupts programmed to wake up
the pcpu at all. In fact, I don't think today there would be any, unless
we set one up in Xen for the specific purpose of interrupting the pcpu
sleep.

I don't know the inner working of the scheduler, but does it always send
an interrupt to other pcpu to schedule something?

What if there are 2 vcpu pinned to the same pcpu? This cannot be fair.

Obviously this behavior cannot be the default. But even if we introduce
it as a command line option, when the user enables it can cause the
whole system to hang if she is not careful. Isn't that right? We have no
way to detect when we can do this safely.

I prefer an option such as vwfi=pool, where in the worst case the user
burns more power but there are no unexpected hangs.


> 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)?

Yes, that would be the benefit.

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