From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] xen: credit1: on vCPU wakeup, kick away current only if makes sense Date: Mon, 2 Nov 2015 14:43:33 +0100 Message-ID: <1446471813.3829.31.camel@citrix.com> References: <20151029105742.22610.76705.stgit@Solace.station> <5637511E.5030107@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5024374570071503324==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZtFOj-0006NT-0e for xen-devel@lists.xenproject.org; Mon, 02 Nov 2015 13:43:45 +0000 In-Reply-To: <5637511E.5030107@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , xen-devel@lists.xenproject.org Cc: suokun , Kun Suo List-Id: xen-devel@lists.xenproject.org --===============5024374570071503324== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aXkdF7NWwXlCpoEGaaIS" --=-aXkdF7NWwXlCpoEGaaIS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-11-02 at 12:03 +0000, George Dunlap wrote: > On 29/10/15 10:57, Dario Faggioli wrote: > > In particular, 1) has been reported to cause the following > > issue: > >=20 > > * VM-IO: 1-vCPU pinned to a pCPU, running netperf > > * VM-CPU: 1-vCPU pinned the the same pCPU, running a busy > > CPU loop > > =3D=3D> Only VM-I/O: throughput is 806.64 Mbps > > =3D=3D> VM-I/O + VM-CPU: throughput is 166.50 Mbps > >=20 > > This patch solves (for the above scenario) the problem > > by checking whether or not it makes sense to try to > > migrate away the vCPU currently running on the processor. > > In fact, if there aren't idle processors where such a vCPU > > can execute. attempting the migration is just futile > > (harmful, actually!). > >=20 > > With this patch, in the above configuration, results are: > >=20 > > =3D=3D> Only VM-I/O: throughput is 807.18 Mbps > > =3D=3D> VM-I/O + VM-CPU: throughput is 731.66 Mbps > >=20 > > Reported-by: Kun Suo > > Signed-off-by: Dario Faggioli > > Tested-by: Kun Suo >=20 > I'm getting a bit worried about how long the path is to actually wake > up > a vcpu; if this only affected the "pin" case, then I might say it > wasn't > worth it. =20 > Same here. That's why I started looking at a solution that was more general that the pinned scenario, for which it wasn't worth adding complexity in the wakeup path. I've got a patch for that almost ready (avoiding boosting in case of wakeups induced by a migration). However, while working on that, I realized... > But it looks to me like this could be a consistent pattern on > any system where there was consistently no idlers available; so at > this > point it's probably better to have than not: >=20 ...exactly this. I.e., it's not only the pinned case. Even 'free'=20 vCPUs, or vCPUs with arbitrary large affinities, if the system is busy, can incur into this sort of spurious migration attempts, with takes time (migrate-->pick-->wake-->tickle-->rescheduling), and yet leaves the situation unchanged (with the fix I'm preparing; without, it causes the reported anomaly). At that point, this, and the boosting after migration, became two orthogonal issues, both needing fixing. :-/ > Acked-by: George Dunlap > Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-aXkdF7NWwXlCpoEGaaIS 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 v1 iEYEABECAAYFAlY3aIUACgkQk4XaBE3IOsSL9QCfVglOiJvMnDUbKWArErrMf3oe r8cAn1selZznKLezEIRMGX/OOUyyvR1x =dHKU -----END PGP SIGNATURE----- --=-aXkdF7NWwXlCpoEGaaIS-- --===============5024374570071503324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5024374570071503324==--