[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/arm: introduce vwfi parameter
Hi Dario, On 20/02/17 19:20, Dario Faggioli wrote: On Mon, 2017-02-20 at 18:53 +0000, Julien Grall wrote:On 20/02/17 18:47, Stefano Stabellini wrote:This is a good question, I have already answered: I think it would break the scheduler. Dario confirmed it in his reply (1487382463.6732.146.camel@xxxxxxxxxx).I don't think it will break the scheduler, we are trapping WFI/WFE to take advantage of the quiescence of the guest. If we don't do that, the guest will just waste his slot.Err... Wait... WF* basically puts a _pCPU_ to sleep until something happens (interrupt or event). This is not something we let a guest _vCPU_ do! E.g., if vCPU x of domain A wants to go idle with a WFI/WFE, but the host is overbooked and currently really busy, Xen wants to run some other vCPU (of either the same of another domain). That's actually the whole point of virtualization, and the reason why overbooking an host with more vCPUs (from multiple guests) than it has pCPUs works at all. If we start letting guests put the host's pCPUs to sleep, not only the scheduler, but many things would break, IMO! I am not speaking about general case but when you get 1 vCPU pinned to 1 pCPU (I think this is Stefano use case). No other vCPU will run on this pCPU. So it would be fine to let the guest do the WFI. If you run multiple vCPU in the same pCPU you would have a bigger interrupt latency. And blocked the vCPU or yield will likely have the same number unless you know the interrupt will come right now. But in that case, using WFI in the guest may not have been the right things to do. I have heard use case where people wants to disable the scheduler (e.g a nop scheduler) because they know only 1 vCPU will ever run on the pCPU. This is exactly the use case I am thinking about. Even if the WFI is done by the guest, you will receive the scheduler interrupt in Xen and that's fine. Did I miss anything?Maybe it's me that am missing what you actually mean here. What do you mean with "you will receive the scheduler interrupt"? Right now, HLT in guest means block in Xen, which makes the scheduler run and decide whether the pCPU should stay idle, or run someone else. I'd say that no good can come from having HTL in guest automatically meaning also on the pCPU. So, I'm not sure what we're talking about, but what I'm quite sure is that we don't want a guest to be able to decide when and until what time/event, a pCPU goes idle. Well, if the guest is not using the WFI/WFE at all you would need an interrupt from the scheduler to get it running. So here it is similar, the scheduler would have setup a timer and the processor will awake when receiving the timer interrupt to enter in the hypervisor. So, yes in fine the guest will waste its slot. But this is what would have happen if the guest is not using any of the WFI/WFE instructions. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |