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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2924 bytes --]

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

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

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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