From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] xen/arm: introduce vwfi parameter Date: Mon, 20 Feb 2017 20:20:36 +0100 Message-ID: <1487618436.6732.230.camel@citrix.com> References: <1487286292-29502-1-git-send-email-sstabellini@kernel.org> <484f2a39-1322-f40e-de01-97746e5de280@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6998764631202019894==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cftVy-0002T3-A6 for xen-devel@lists.xenproject.org; Mon, 20 Feb 2017 19:20:50 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Julien Grall , Stefano Stabellini Cc: edgar.iglesias@xilinx.com, george.dunlap@eu.citrix.com, nd@arm.com, Punit Agrawal , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============6998764631202019894== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-phrleiH+bvy+JU5ab4Y/" --=-phrleiH+bvy+JU5ab4Y/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@citrix.com). >=20 > I don't think it will break the scheduler, we are trapping WFI/WFE > to=C2=A0 > take advantage of the quiescence of the guest. If we don't do that, > the=C2=A0 > guest will just waste his slot. >=20 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! > Even if the WFI is done by the guest, you will receive the scheduler=C2= =A0 > interrupt in Xen and that's fine. Did I miss anything? >=20 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. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-phrleiH+bvy+JU5ab4Y/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYq0GFAAoJEBZCeImluHPuFEQQAJOQnKIDtzKt82NU/4561uUi 1b/hCwPu2KwBQvnPIDzUyOw+w9TRWyr+x0W50h5ZwDvG15/W/ZNHgT2KcAgv4Sc4 7aaod1GgHpqWXJVYtvlnpaCuROApzYWVBMBuS/fdrqk3pVzdo5f/cQ4YjBIRtQKv 2SWN+KaOEXZUWvRoiKGhirmD+HNOf6iw2fDiXApPoZ1qLJkmPXXoA485ouHKUyGJ c5b64p3n1Uw7p/qSkZPA/qOAYPU89MS+ptwzpQb2xqPVREidVZ7x/Zri1VkKCf0j bh/uBM/jXe0eYZZEaV4fbC58kAQXzMpCzA9PUqyS0O6L6kV4/kNzdR6nXzxc3jmV 0lhSn7bV6XESWmM689xhEkoPZxltsA5W/PAxZrf5Hr83dvuyZSnPgu3x9izyCznK 0A7fsAuCoOP1vhPzskf9xFXzqVhyLHQzDrExmLq6ZRXReJvlusK9KnqxXjeT4IQ4 rKNvG2g7SzOF17ngGrOfUINWqdAgH0nyiGwLXookYQebpwgbBzjWjAjBQGwLxcHJ FFxprnQ0nXcW5Bq8DgYFRYiHsYNR7FCK+z8iJ7ykUr1sAhIBQ/ymGr2BBoRbTIsu EHGKWdUTQSkOy8h7txkeBLp8ezxoxb7t+jYnUFnRVczLNUgCJ9JAtDqRJZPyYWUN d/t0QiQiBBgMvfym8KY1 =kqK0 -----END PGP SIGNATURE----- --=-phrleiH+bvy+JU5ab4Y/-- --===============6998764631202019894== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6998764631202019894==--