Re: [PATCH] xen/arm: introduce vwfi parameter

[Julien Grall <julien.grall@arm.com>]

Hi Dario,

On 21/02/17 09:24, Dario Faggioli wrote:
> On Tue, 2017-02-21 at 08:10 +0000, Julien Grall wrote:
>> On 21/02/2017 00:38, Stefano Stabellini wrote:
>>> On Mon, 20 Feb 2017, Dario Faggioli wrote:
>>>> Mmm... ok, yes, in that case, it may make sense and work, from a,
>>>> let's
>>>> say, purely functional perspective. But still I struggle to place
>>>> this
>>>> in a bigger picture.
>>>
>>> I feel the same way as you, Dario. That said, if we could make it
>>> work
>>> without breaking too many assumptions in Xen, it would be a great
>>> improvement for this use-case.
>>
>> Again, there is no assumption broken. Using WFI/WFE is just a nice
>> way
>> to say: "You can sleep and save power" so a scheduler can decide to
>> schedule another vCPU. Obviously a guest is free to not use them and
>> could do a busy loop instead.
>>
> Again, other way round. It is a scheduler that, when a CPU would go
> idle, decides whether to sleep or busy loop.
>
> It's the Linux scheduler that, in Linux, on x86, decides whether to HLT
> (or use MWAIT and that stuff) during the idle loop (which is what
> happens by default) or not, and hence busy loop (which is what happens
> if you pass 'idle=poll'). And, as far as Linux (and every OS running on
> baremetal), that's it.
>
> In Xen, it's the exact same thing. When the scheduler decides to run
> the idle loop on a pCPU, it's Xen itself (it's, strictly speaking, not
> really the scheduler, because the code is in arch/foo/domain.c, but,
> whatever) that decides whether to sleep --with MWAIT, WFI, etc-- or to
> stay awake. Stay awake would basically mean calling something like
> cpu_relax() idle_loop() (basically, doing, on x86,
> pm_idle=cpu_relax()). We currently don't have a way to tell Xen we want
> that, but it may be added. That would be the _exact_ equivalent of
> Linux's 'idle=poll'. And that is _not_ what this patch does.
>
> In fact, still in Xen, we also have to decide what to do when one of
> our guests' vCPUs goes idle. This is where, I feel, at least part of
> the misunderstanding going on in this thread is actually happening...

Likely :). I would be happy to have idle_loop to be a busy loop. But I 
don't think this will solve Stefano's problem (see my answer [1]) 
because the underlying problem is using the idle vCPU on ARM is really 
expensive.

>
>>> Right, I asked myself those questions as well. That is why I wrote
>>> "it
>>> breaks the scheduler" in the previous email. I don't think it can
>>> work
>>> today, but it could work one day, building on top of the nop
>>> scheduler.
>>
>> WFE/WFI is only a hint for the scheduler to reschedule. If you don't
>> trap them, the guest will still run until the end of its credit. It
>> doesn't break anything.
>>
> And in fact, I totally fail to understand what you mean here. By "don't
> trap them" do you mean just ignore them? Or do you mean execute them on
> hardware?

I mean executing on the hardware. My whole point was about WFI/WFE 
executed by the guest and not Xen.

Cheers,

[1] <14575011-0042-8940-c19f-2482136ff91c@foss.arm.com>

-- 
Julien Grall

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