From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/3] xen: Remove buggy initial placement algorithm Date: Sat, 16 Jul 2016 15:55:07 +0200 Message-ID: <1468677307.13039.116.camel@citrix.com> References: <1468605722-24239-1-git-send-email-george.dunlap@citrix.com> <1468605722-24239-3-git-send-email-george.dunlap@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6315526365433596915==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOQ45-0000WF-Bw for xen-devel@lists.xenproject.org; Sat, 16 Jul 2016 13:55:33 +0000 In-Reply-To: <1468605722-24239-3-git-send-email-george.dunlap@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: Stefano Stabellini , Wei Liu , Andrew Cooper , Anshul Makkar , Ian Jackson , Tim Deegan , Meng Xu , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============6315526365433596915== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-0w1h0o1fi/vC3sefVHd8" --=-0w1h0o1fi/vC3sefVHd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-07-15 at 19:02 +0100, George Dunlap wrote: > The initial placement algorithm sometimes picks cpus outside of the > mask it's given, does a lot of unnecessary bitmasking, does its own > separate load calculation, and completely ignores vcpu hard and soft > affinities.=C2=A0=C2=A0 > Not to mention that I wouldn't even call what it does "load calculation". It just counts the number of vcpus that are executing (or have executed their last instance) on each CPU, which tells very few about load. And it does that without any locking at all, which I see the reason why, but the net effect is that the final result comes from a wrong calculation done on unreliable data... I don't see how this could be more broken! :-P > Just get rid of it and rely on the schedulers to do > initial placement. >=20 This all makes a lot of sense to me, and I'm all for it, thanks for doing it! :-) > Signed-off-by: George Dunlap > --- > Since many of scheduler cpu_pick functions have a strong preference > to > just leave the cpu where it is (in particular, credit1 and rt), this > may cause some cpus to be overloaded when creating a lot of domains. > Arguably this should be fixed in the schedulers themselves. >=20 Indeed. Still, maybe... > @@ -691,7 +643,7 @@ long > do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0continue; > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0cpu =3D (i =3D=3D 0) ? > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0default_vcpu0_location(online) : > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0cpumask_first(online) : > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cpumask_cycle(d->vcpu[i-1]->processor, online= ); > ...cpumask_any() ? It's a bit more expensive, but it at least would provided a less biased (toward lower CPU indexes) basis to the schedulers? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-0w1h0o1fi/vC3sefVHd8 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 iQIcBAABCAAGBQJXijzJAAoJEBZCeImluHPuYKcQANMKNNqr04AxZaFnPsjfekxr 6lUbcfCeZTvLDbBq/VBwfjGdlzBZk53c08iJaOdUngED3EwIIp8DzMf1PColFCTB ydaysASjbUMGeEvrLktDdyYWFLxL5uePCERtkR2TNpm9HlgGgyAmVIQl8P9Yb+v2 Yz+EV+xsiWJdFlYbpMYQSZI91vu1lVVMXmIoCAuZuFvWFKIIQ8UXHe3YMzfyYK+/ QT2qwRSoBedF6m2NbJCLivOdP/DaiUWoZW7zGpstUU+IRX83hNqgTYO/0g2JTI6X xVncsng2tPTR+/S+bKeA50mCBesJBnh8IavkGSj57p0MysnxNEmzx5uNkshbIt/e Qd/5n4p/PK0rnAFRNJ3Ng4FQS7BefN7AAHDHAEuq5aBD+mMExMEgfr194XC7D01v fqLj4VdxXZiIui+HKvwUDFmdd4dL4UIko+md4S+kxXPxpkwyswjAmqb08Al9ISLz eMPPjXZiD9If45dVt2mvb5YbHZbzGB8l0U6FIAMPibpDtwzKMRjcNnB7LADl13GI uQQHDX7FEzgE1zvAWtWXe974puj9TktO3nfnyY1a4nRi6jk8uGFINUt3K3T+0eNV qIw4nbi/6UfCm5pQ/AbIHSb2xy6AGaNS3uMSavXUf7P6tU5TjCp2KozkguZZqaQ8 k6lr/Ntd2VYE49hkt+aM =knwS -----END PGP SIGNATURE----- --=-0w1h0o1fi/vC3sefVHd8-- --===============6315526365433596915== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6315526365433596915==--