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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 19/02/17 21:27, Julien Grall wrote:
> Hi Dario,
> 
> On 02/18/2017 01:47 AM, Dario Faggioli wrote:
>> On Fri, 2017-02-17 at 14:50 -0800, Stefano Stabellini wrote:
>>> On Fri, 17 Feb 2017, Julien Grall wrote:
>>>> Please explain in which context this will be beneficial. My gut
>>>> feeling is
>>>> only will make performance worst if a multiple vCPU of the same
>>>> guest is
>>>> running on vCPU
>>>
>>> I am not a scheduler expert, but I don't think so. Let me explain the
>>> difference:
>>>
>>> - vcpu_block blocks a vcpu until an event occurs, for example until
>>> it
>>>   receives an interrupt
>>>
>>> - vcpu_yield stops the vcpu from running until the next scheduler
>>> slot
>>>
>> So, what happens when you yield, depends on how yield is implemented in
>> the specific scheduler, and what other vcpus are runnable in the
>> system.
>>
>> Currently, neither Credit1 nor Credit2 (and nor the Linux scheduler,
>> AFAICR) really stop the yielding vcpus. Broadly speaking, the following
>> two scenarios are possible:
>>  - vcpu A yields, and there is one or more runnable but not already
>>    running other vcpus. In this case, A is indeed descheduled and put
>>    back in a scheduler runqueue in such a way that one or more of the
>>    runnable but not running other vcpus have a chance to execute,
>>    before the scheduler would consider A again. This may be
>>    implemented by putting A on the tail of the runqueue, so all the
>>    other vcpus will get a chance to run (this is basically what
>>    happens in Credit1, modulo periodic runq sorting). Or it may be
>>    implemented by ignoring A for the next <number> scheduling
>>    decisions after it yielded (this is basically what happens in
>>    Credit2). Both approaches have pros and cons, but the common botton
>>    line is that others are given a chance to run.
>>
>>  - vcpu A yields, and there are no runnable but not running vcpus
>>    around. In this case, A gets to run again. Full stop.
> 
> Which turn to be the busy looping I was mentioning when one vCPU is
> assigned to a pCPU. This is not the goal of WFI and I would be really
> surprised that embedded folks will be happy with a solution using more
> power.

Yes, I'm afraid if there are no other vcpus to run on the pcpu that it
would indeed be busy-waiting.  So 'idle' would be a misdleading name for
that option; it should be 'poll'.

Yield is only advisory -- it says, "I'm doing something somewhat
low-priority; if there's something more useful you could be doing go
ahead and do it."  There is no promise about what, if anything, a yield
call will do.  For a long time credit1 didn't actually do anything on a
yield -- it simply went through the scheduler, which normally ended up
choosing the exact same vcpu again (even when there was other things to
do).  Doing something sensible with that information is not actually as
easy as one might think.

So we should avoid designing any mechanisms that rely on a particular
implementation of yield().

 -George


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