[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |