From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [DOC RFC] Heterogeneous Multi Processing Support in Xen Date: Thu, 8 Dec 2016 22:45:48 +0100 Message-ID: <1481233548.3445.175.camel@citrix.com> References: <1481135379.3445.142.camel@citrix.com> <3f9a7da1-7c05-e082-99d2-302dbeee61b9@suse.com> <1481192825.3445.157.camel@citrix.com> <8ee2f981-fdad-63e2-5779-02fedc7d137d@suse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5152466796394320018==" Return-path: In-Reply-To: <8ee2f981-fdad-63e2-5779-02fedc7d137d@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Juergen Gross , Xen Devel Cc: Peng Fan , Stefano Stabellini , George Dunlap , Andrew Cooper , anastassios.nanos@onapp.com, Jan Beulich , Peng Fan List-Id: xen-devel@lists.xenproject.org --===============5152466796394320018== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-TzLhQPblEVkxFPSUjU4w" --=-TzLhQPblEVkxFPSUjU4w Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-12-08 at 11:38 +0100, Juergen Gross wrote: > On 08/12/16 11:27, Dario Faggioli wrote: > > On Thu, 2016-12-08 at 07:12 +0100, Juergen Gross wrote: > > > Any idea how to avoid problems in the schedulers related to vcpus > > > with > > > different weights?=C2=A0 > > >=20 > > Sure: use Credit2! :-P > >=20 > > And I'm not joking (not entirely, at least), as the alternative is > > to > > re-engineer significantly the algorithm inside Credit, which I'm > > not > > sure is doable or worthwhile, especially considering we have > > alternatives. >=20 > So you really solved the following problem in credit2? >=20 So, pinning will always _affect_ scheduling, that is actually its goal. And in fact, it really should be used when there is no alternative, or when the scenario is understood well enough, that its effects are known (or at least known to be beneficial for the workload running on the host). In Credit2, weights used to make a vCPU burn credits faster or slower than the other vCPUs, while in Credit1, the algorithm is much more complex. Also, in Credit2, everything is computed per-runqueue. Pinning of course interferes, but should really be less disruptive than in Credit1. All this being said, I was not yet around when you came up with the idea that pinning was disturbing weighted fairness, so I'm not sure what the original argument was... I'll go back check the email conversation in the archive. And again, all the times that one can use cpupool, that should be the preferred solution, but there are situations where that's just not suitable, and we need pinning. This case is a little bit border-line. Sure using pinning is not ideal, and in fact it's only happening in the initial stages. When actually modifying the scheduler, we will, in Credit2, do something like having one runqueue per class (or more, but certainly not any runqueues that "cross" classes, as that would not work), which puts us in a pretty decent situation, I think. For Credit, let's see, but I'm afraid we won't be able to guarantee much more than technical correctness (i.e., not scheduling on forbidden classes). > You have three domains with 2 vcpus each and different weights. Run > them > on 3 physical cpus with following pinning: >=20 > dom1: pcpu 1 and 2 > dom2: pcpu 2 and 3 > dom3: pcpu 1 and 3 >=20 > How do you decide which vcpu to run on which pcpu for how long? >=20 Ok, it was a public holiday here today, so I did not really have time to think about this example. And tomorrow I'm on PTO. I'll look closely on Monday. 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) --=-TzLhQPblEVkxFPSUjU4w 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 iQIcBAABCAAGBQJYSdSQAAoJEBZCeImluHPu7UYP/3nQ9tdpoKkEQaqG8n5AGazm sB8dk3j9vGVoD3C65hK/PQoZ+cWfWgl9gPMQDwB5tzLSB1EKvF9lIeNI9LJBsvCM OMUzgg9qFSvZlYzjcTvKRvX7SZ7/lP+lid2/vOzmcZG//blKOoejpNWZshO20u/c 9a3nvXLwVK56I1cxmmgRqSu21E3a+Swz1qJzvqYY1tjM9vOZdYhhtI7yoaChkkGS cKt929GeMFkW4UjLKpRhCgiY2qpYtFmnsyWhPy672o3omQbhkKITy+nTVX92Sd3K JY/UtaQCLK9yw85iXF+VQEcBOv2LlHNXxbKt7PcFGrhPY/3VFmn7qJuOB01Xc4D1 cN90csArQlPeyGHvej6HVrcpnIpXE494tELSCNXWQvDIO/J3BzQRoHCRNyvs3ovL snFts+I/8iRnHry3wHkbEEuGEc+slDBLfWg5Iwaktfwgbd5mdSFr1J2gHeOhssQJ 0q5TvB8nXKueuQOXkQkhgoI2ZmaNf+a5Cv60GxzOwe+MJAJ3xdlmpK40Px9a/a8c SKPA+4THTjh6EzfmSos47ncoLCz6ddkVT4GCCK+7Mj0pWQSyeUKAadO5tXq+7hd2 o1ZLJpbWFtlLAZBf4cNLFgDWjTO/uk6lVgoZGWxZLxtty+eUIxZ6BIDXTqlss893 Eq+ew0vYAbhfwcGE2tlI =PKI5 -----END PGP SIGNATURE----- --=-TzLhQPblEVkxFPSUjU4w-- --===============5152466796394320018== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5152466796394320018==--