From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] xen/arm: introduce vwfi parameter Date: Tue, 21 Feb 2017 16:07:11 +0100 Message-ID: <1487689631.6732.412.camel@citrix.com> References: <1487286292-29502-1-git-send-email-sstabellini@kernel.org> <484f2a39-1322-f40e-de01-97746e5de280@arm.com> <1487618436.6732.230.camel@citrix.com> <1845466e-c6a3-bcb9-0813-80ecdf267f03@arm.com> <1487631215.6732.266.camel@citrix.com> <06f20feb-0e9e-c757-b245-ebb55b422c67@arm.com> <1487668158.6732.310.camel@citrix.com> <14575011-0042-8940-c19f-2482136ff91c@foss.arm.com> <6a7b800a-dd6a-15a2-665d-d28352f24cd1@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8627076585874945181==" 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 1cgC2I-0005vv-AG for xen-devel@lists.xenproject.org; Tue, 21 Feb 2017 15:07:26 +0000 In-Reply-To: <6a7b800a-dd6a-15a2-665d-d28352f24cd1@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , 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 --===============8627076585874945181== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-Za4XizgAlzjPO7grkpwe" --=-Za4XizgAlzjPO7grkpwe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-02-21 at 13:46 +0000, George Dunlap wrote: > > A.=C2=A0=C2=A0Don't trap guest WFI at all -- allow it to 'halt' in > moderate-power-but-ready-for-interrupt mode. >=20 > [..] > > A is safe because the scheduler should already have set a timer to > break > out of it if necessary.=C2=A0=C2=A0The only potential issue here is that = the > guest > is burning its credits, meaning that other vcpus with something > potentially useful to do aren't being allowed to run; and then later > when this vcpu has something useful to do it may be prevented from > running because of low credits.=C2=A0=C2=A0(This may be what Dario means = when > he > says it "breaks scheduling"). >=20 Are you also referring to the case when there are less vCPUs around than the host has pCPUs (and, ideally, all vCPUs are pinned 1:1 to a pCPU)? If yes, I agree that we're probably fine, but we have to check and enforce all this to be the case. If no, think at a situation where there is 1 vCPU running on a pCPU and 3 vCPUs in the runqueue (it may be a per-CPU Credit1 runqueue or a shared among some pCPUs Credit2 runqueue). If the running vCPU goes idle, let's say with WFI, we _don't_ want the pCPU to enter neither moderate nor deep sleep, we want to pick up the first of the 3 other vCPUs that are waiting in the runqueue. This is what I mean when I say "breaks scheduling". :-) Oh, actually, if --which I only now realize may be what you are referring to, since you're talking about "guest burning its credits"-- you let the vCPU put the pCPU to sleep *but*, when it wakes up (or when the scheduler runs again for whatever reason), you charge to it for all the time the the pCPU was actually idle/sleeping, well, that may actually =C2=A0not break scheduling, or cause disruption to the service of other vCPUs.... But indeed I'd consider it rather counter intuitive a behavior. In fact, it'd mean that the guest has issued WFI because he wanted to sleep and we do put it to sleep. But when it wakes up, we treat it like it had busy waited. What would be the benefit of this? That we don't context switch (either to idle or to someone else)? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Za4XizgAlzjPO7grkpwe 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 iQIcBAABCAAGBQJYrFehAAoJEBZCeImluHPuvcoQALJpefMOOVmyBgOfLodRZA95 ni6oSZY2p6Fn81VZS/NXryynbrN57EbvevGtVV7BkAKz1fWK8ntHNJfoyvoa7Bw3 86Qk7KPK1uFTlm/8osLhbCkHJ07hL0cF5SmTBs0pR3eeScl3/Z/6IrraloW75VAh C7pmkxeth5cnG/CmsyR/IuzIVnIaERPrNvhOavZw5VcBvq6vybfqb/uKuKAj4u6z rLVXWsDOUhTZrZra+Mekj97Rm9bTTRGotlnL1GG8evwbe6SGi1C2axq4LbFMHj6S NTNlDHI/6Z8vX0tJRcrm8hLtS+hoU3GleXQGsCQt1wZiXJdmpTtk0O9sK6dtZ4p/ e1sM7QAPOPjr4OrTe91bKs3xpS851xJEc/8JQW/7FyHSYhsTBZ1tZC0GQUphTKJ4 o0GyW9C3Tq4VWnFVHqYb5zg90VjI9gyqKBOglM6AxfBivNzahzK0bc31/6CXChXy bMwA7yxXfCIivENmEGTxYrYgpzx2Q4qnXqOe7wfkQH51cRW4o72uxygO2XNevDse ZsB9TZVWmV11GuBbqijSdeWcV6h/1rlD2MsglWhJua2Rx7IUv0S8BZJhevFf4dql eLAQo5U2l9Fj3iewuNDbMnkc0YIntAeaa2JDViqk2CLN8O9OYBCi8p8Lbbn2WAUe 5kJfsMazU0pA5zmauQeD =Qw9w -----END PGP SIGNATURE----- --=-Za4XizgAlzjPO7grkpwe-- --===============8627076585874945181== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============8627076585874945181==--