From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 3/4] xen: sched: improve checking soft-affinity Date: Thu, 05 Oct 2017 15:51:49 +0200 Message-ID: <1507211509.4127.19.camel@linux.it> References: <150549688701.28881.16283579243927231378.stgit@Solace.fritz.box> <150549692333.28881.4639203280111560477.stgit@Solace.fritz.box> <25b5d7c6-7402-6101-2432-50378bbeb232@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3336815397894688253==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e06ZG-0001sX-VX for xen-devel@lists.xenproject.org; Thu, 05 Oct 2017 13:52:03 +0000 Received: by mail-wm0-f65.google.com with SMTP id u138so2257570wmu.5 for ; Thu, 05 Oct 2017 06:51:54 -0700 (PDT) In-Reply-To: <25b5d7c6-7402-6101-2432-50378bbeb232@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 --===============3336815397894688253== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-CM5kb02ArxXAwDuC6BBf" --=-CM5kb02ArxXAwDuC6BBf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2017-10-04 at 14:23 +0100, George Dunlap wrote: > On 09/15/2017 06:35 PM, Dario Faggioli wrote: > >=20 > > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c > > index 3efbfc8..35d0c98 100644 > > --- a/xen/common/sched_credit.c > > +++ b/xen/common/sched_credit.c > > @@ -410,8 +410,7 @@ static inline void __runq_tickle(struct > > csched_vcpu *new) > > int new_idlers_empty; > > =20 > > if ( balance_step =3D=3D BALANCE_SOFT_AFFINITY > > - && !has_soft_affinity(new->vcpu, > > - new->vcpu- > > >cpu_hard_affinity) ) > > + && !has_soft_affinity(new->vcpu) ) > > continue; > > =20 > > /* Are there idlers suitable for new (for this balance > > step)? */ > > @@ -743,50 +742,42 @@ __csched_vcpu_is_migrateable(struct vcpu *vc, > > int dest_cpu, cpumask_t *mask) > > static int > > _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc, > > bool_t commit) > > { > > - cpumask_t cpus; >=20 > Is there a reason you couldn't use cpumask_t > *cpus=3Dcpumask_scratch_cpu()? >=20 I was about to say "yes, of course". But while double checking that, I realized that the patch is actually wrong. So, even if not 100% intentional... good catch! :-P In fact, in this function (_csched_cpu_pick()), cpu potentially changes here: cpu =3D cpumask_test_cpu(vc->processor, cpumask_scratch_cpu(cpu)) ? vc->processor : cpumask_cycle(vc->processor, cpumask_scratch_cpu(cpu)); and here: if ( !cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu)) && !cpumask_empty(cpumask_scratch_cpu(cpu)) ) cpu =3D cpumask_cycle(cpu, cpumask_scratch_cpu(cpu)); And it's therefore not ok to continue to use cpumask_scratch_cpu(cpu). I now have fixed this, but then, while testing, I discovered more, and much more serious issues. I'm not actually sure what happened, but it's quite clear I've made a mess while testing this series (likely, I must mistakenly have tested a different version of the series, wrt to that I sent). So I'll send a v3, with the issues I've found fixed, and this time properly tested. Sorry everyone, George in particular. :-( Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-CM5kb02ArxXAwDuC6BBf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAlnWOPYACgkQFkJ4iaW4 c+78QBAAjHk6i15++6nkysb1jop5mGNfZ3E2r4kxSmtjKJ+tLjqxmgYoBLTC27pU UI6IWFj63yL45iLVIO6RVuayu1YILw1X+8Stdd07n3T6igk+wZ+UI4md3EMK1LA7 lPrv3jFYvjjjBTREFYIU4dCHsOSjzA3tvYZSz6sFz5j8oiCdWwFOLKr0ha5ec2wW sp003VEzT2vURz4jkIdj+O7F30rnwCp/hRRPrlB8pD9XwzNo/UymzybDjz8yO3al /X0HgwrWhXuAWo80X4vZZj4qVLbOWeqY1i7BrMQ9l72pTXhdrFNu6hIcUv5tZgHy Jk5hZLrbBTVzuk9/Zo7fuyDtoIPDxUfxRdJcN7JQq573PdyW69GuFmaWAP0RXJmP VlvP8NISRTeNYLPbAyYYnVk2QvoRiPd8FiwWLqjuiCwrBgfTec4C62H7dQgKLSvl XG7beBi+0RjBXGY8sxswnq6Bh2HrlMgYagssljhy9NgoKIKm245sYrKg+R8LhjaO 9L02g8R+3WXkz9JTrKGmF7PQ3C7uQADJya0WnGE1wON48srIsTKhq7zIAQi4KejY x556EH+1lQv1RL6G58vRDne7TN9muZaSXf0ah4z8LBr5N7tnPAz92ARJedTepqne awkGj2m7/VmHE+Nw6+4j60Ck6+zz8VeSb7f/aBE+5QgStEwTm6A= =dQj/ -----END PGP SIGNATURE----- --=-CM5kb02ArxXAwDuC6BBf-- --===============3336815397894688253== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============3336815397894688253==--