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

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxx>

--
Julien Grall

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