From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC 0/5] xen/arm: support big.little SoC Date: Mon, 19 Sep 2016 18:43:28 +0200 Message-ID: <1474303408.4393.16.camel@citrix.com> References: <1474250936-27962-1-git-send-email-peng.fan@nxp.com> <10152e13-bccb-0794-44e4-556845875e33@arm.com> <20160919083619.GA16854@linux-7smt.suse> <5ddefbc1-3bd4-c990-b615-0039761535d8@arm.com> <170e2787-a410-37c5-a675-6fc7cf31ad6f@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7509055876945318777==" Return-path: In-Reply-To: <170e2787-a410-37c5-a675-6fc7cf31ad6f@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 , George Dunlap Cc: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= , Peng Fan , Stefano Stabellini , Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich , Peng Fan List-Id: xen-devel@lists.xenproject.org --===============7509055876945318777== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-OqoMEtKuyf7QzwFa+fXm" --=-OqoMEtKuyf7QzwFa+fXm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-19 at 11:33 +0100, George Dunlap wrote: > On 19/09/16 11:06, Julien Grall wrote: > > So, if I understand correctly, you would not recommend to extend > > the > > number of CPU pool per domain, correct? >=20 > Well imagine trying to set the scheduling parameters, such as weight, > which in the past have been per-domain.=C2=A0=C2=A0Now you have to specif= y > parameters for a domain in each of the cpupools that its' in. >=20 True, and not really convenient indeed. I think we can think of a way to shape the interface in such a way that it's not too bad to use (provide sane defaults/default behavior, etc), but this should be definitely kept in mind. In general, I agree with Juergen that, before implementing anything, we must come up with a design, bearing in mind both behavior and interface. (I'll reply in some more details directly to Juergen's email.) > No, I think it would be a lot simpler to just teach the scheduler > aboutIf we want to support heterogeneous CPUs, some like this is > absolutely necessary. In fact, either we set (and enforce) very > strict rules on cpupools and pinning, or we'd end up scheduling stuff > built for arch A on a processor of arch B! :-O > different classes of cpus.=C2=A0=C2=A0credit1 would probably need to be > modified > so that its credit algorithm would be per-class rather than pool- > wide; > but credit2 shouldn't need much modification at all, other than to > make > sure that a given runqueue doesn't include more than one class; and > to > do load-balancing only with runqueues of the same class. >=20 If we want to support heterogeneous CPUs, some like this is absolutely necessary. In fact, either we set (and enforce) very strict rules on cpupools and pinning, or we'd end up scheduling stuff built for arch A on a processor of arch B! :-O The "strict limits" approach may be an option --and this patch is a first example of it-- but it's easy to see that it's very inflexible (cpus can't move between pools, domains can't be migrated, etc). On the other hand, as soon as we "relax" the constraints a little bit, we absolutely need to modify the scheduler code to avoid bad things to happen. As George is saying, both Credit1 and Credit2 needs to be modified in order to make sure that a vcpu that is meant to run on a big cpu is not picked up for being executed by a LITTLE cpu. This has to do with tweaking the load balancing code in both of them (e.g., in Credit1, a LITTLE cpu must not steal work from a big cpu). Whether or not it will also be required to change the Credit-ing algorithm, it will have to be seen. The effect would be similar to some sort of pinning, which indeed does not play well with Credit1 accounting logic... but we can probably see about this along the way (or just focus only con Credit2! :-P) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-OqoMEtKuyf7QzwFa+fXm 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 iQIcBAABCAAGBQJX4BWwAAoJEBZCeImluHPurN0P/1Pb1nWkgB/SG3ReF6e62Hqy X4IGN7HSKVcjDuCx9832ZAVxXNz1fjjHnNDaxstEVVM5xcz+1poYDywx1c1zxnsY y5z2oj6D9tfI4zF4Ou8oFzYW2YFQTZHDQWPzGf1YErxI/1XwadtPFWC+1XtbjvC3 f7AroDydRFsDkncqgQEqmHohflTfIiCpw0cWCG8FO4AZMSqq3dLivWXW6bhYLNIo Qfy0K6G+g2PQt0uYVovoTvCOrF3f0swZwYoqPH25kkT8o3m/6SZOEsDFtB1f36l+ sT/5WoJIK+fc7zhguztO8DINDxPDjEhp9k0jEZ8Yl6qPCgDWS10hZIo7dcgHiJs2 biYZc3d5xGZZ7ihnANoqXRFICEWmgjF3waB1THfatjLDAn6uZ761Iw6/pn2TNmfE bJCD6nLYXw+EhPdQHBF1YnC+rDUvYSae7fFja/q0E7YGO93zeeKYXbFbL25r0bYy z/c20RA7ZNfw5Ra7/gGGj2YlmMzA3a09vA7AvCs4VTXKPidqX5yxzQpA+3GpScaL t3q4jW1qryrTX7JuyFwG2/ewet088AzvAvTFpZCQVfRqIA4CybrXvlwg7M+uE3/r j01XyK+skwGYPTIM3JPpF7zVzk7f7GfpsMYqyLbtBhgo9JXDxpEZUGD0Y+CISddK x0gtUOCUv/Iz+RcMIGFY =fRwS -----END PGP SIGNATURE----- --=-OqoMEtKuyf7QzwFa+fXm-- --===============7509055876945318777== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7509055876945318777==--