From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 6/6] xen: sched: optimize exclusive pinning case (Credit1 & 2) Date: Fri, 21 Jul 2017 21:55:52 +0200 Message-ID: <1500666952.22958.7.camel@citrix.com> References: <149821475587.5914.12193327340105859241.stgit@Solace> <149821532649.5914.2989728748602173556.stgit@Solace> <5962f895-18af-7180-0514-66b25c95d084@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0316045602212790648==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dYe1m-0004Kk-SE for xen-devel@lists.xenproject.org; Fri, 21 Jul 2017 19:55:58 +0000 In-Reply-To: <5962f895-18af-7180-0514-66b25c95d084@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , xen-devel@lists.xenproject.org Cc: Anshul Makkar List-Id: xen-devel@lists.xenproject.org --===============0316045602212790648== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-FrWVYqoKM8HDrMppXFjh" --=-FrWVYqoKM8HDrMppXFjh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-07-21 at 18:19 +0100, George Dunlap wrote: > On 06/23/2017 11:55 AM, Dario Faggioli wrote: > > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c > > index 4f6330e..85e014d 100644 > > --- a/xen/common/sched_credit.c > > +++ b/xen/common/sched_credit.c > > @@ -429,6 +429,24 @@ static inline void __runq_tickle(struct > > csched_vcpu *new) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0idlers_empty =3D cpumask_empty(&idle_mask= ); > > =C2=A0 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* Exclusive pinning is when a vcpu has h= ard-affinity with > > only one > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* cpu, and there is no other vcpu that h= as hard-affinity with > > that > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* same cpu. This is infrequent, but if i= t happens, is for > > achieving > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* the most possible determinism, and lea= st possible overhead > > for > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* the vcpus in question. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* Try to identify the vast majority of t= hese situations, and > > deal > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* with them quickly. > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*/ > > +=C2=A0=C2=A0=C2=A0=C2=A0if ( unlikely(cpumask_cycle(cpu, new->vcpu->cp= u_hard_affinity)=20 > > =3D=3D cpu && >=20 > Won't this check entail a full "loop" of the cpumask?=C2=A0=C2=A0It's che= ap > enough > if nr_cpu_ids is small; but don't we support (theoretically) 4096 > logical cpus? >=20 > It seems like having a vcpu flag that identifies a vcpu as being > pinned > would be a more efficient way to do this.=C2=A0=C2=A0That way we could ru= n this > check once whenever the hard affinity changed, rather than every time > we > want to think about where to run this vcpu. >=20 > What do you think? >=20 Right. We actually should get some help from the hardware (ffs & firends)... but I think you're right. Implementing this with a flag, as you're suggesting, is most likely better, and easy enough. I'll go for that! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-FrWVYqoKM8HDrMppXFjh 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 iQIcBAABCAAGBQJZclxIAAoJEBZCeImluHPu0rcP/3eauchU1TBaBPOtj9Jus6Lb wBn4oP55H7JTsPC51gxOFGNAMjq6SVhiNZYiYzoxwWjFtVoKuFRKeWPkPUWbdOKO Qme3V/K2tWaA0IhsblkVfOmvaF/f/vVN7G+ixFqxfthjPBwJI3WjQarR9y/5u2xQ qkMwe/A0Ltj58S9r7cWYoxU2rOfWBFa78kAmo/v6Xt7t7yg++NZ4Dx/p0wISGRr0 Uoc5lpKMx6RlGAfo8xHJvcMt1ZQ/Oaxhl6Eo5O332i0fIx/RItyA6lY4VeRGOPSv tyUW19mbFQnBX3zk/yP3+j7F0RMT8TrdJ+WPQ72pUQNBzIVLU5X1t+rNEg5UI4E9 jPWdrXIOKeiGMwy4uA9L9rFdI2awh1d2ip5D4Yuu71PzyV6MwC86H2L+fRzA7Oqz HemDgAvGjPXEm98FQTinLoAN1E/f0Kb8ueAGxiZv4ymfpITJGGsqrvbASocaAdYU q8D5jXI20RDQs3QQDMWLJ8CwSDZwyQpcEbwiVVBWp5GvsF0+eL8tYLQzgu6TtBcX dxYPDQ4/ITy0mgz1KFBwKg6QIAOwS8EAdms0k+UyvjO/F7nKGXuDntKdzHsSnuCY xJ+AgDQWEDZpdQc7BId707ZpPlnc4rFYGScXservDKdoe7jAITFVM8bJXDeDEPv7 uCZPNTV/P8Od3kiQHIhP =QU7d -----END PGP SIGNATURE----- --=-FrWVYqoKM8HDrMppXFjh-- --===============0316045602212790648== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0316045602212790648==--