From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 2/2] xen: credit1: avoid boosting vCPUs being "just" migrated Date: Fri, 12 Feb 2016 15:16:29 +0100 Message-ID: <1455286589.3148.362.camel@gmail.com> References: <20160212093501.16002.32635.stgit@Solace.station> <20160212093705.16002.46867.stgit@Solace.station> <56BDB91102000078000D153D@prv-mh.provo.novell.com> <1455274239.3148.342.camel@citrix.com> Reply-To: raistlin@linux.it Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4933280403418121342==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aUEWR-0000Fn-UB for xen-devel@lists.xenproject.org; Fri, 12 Feb 2016 14:16:36 +0000 Received: by mail-wm0-f54.google.com with SMTP id p63so22591160wmp.1 for ; Fri, 12 Feb 2016 06:16:34 -0800 (PST) In-Reply-To: <1455274239.3148.342.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============4933280403418121342== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9JTYczds3hiMP95QVa8k" --=-9JTYczds3hiMP95QVa8k Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Yes, replying to myself] On Fri, 2016-02-12 at 11:50 +0100, Dario Faggioli wrote: > On Fri, 2016-02-12 at 02:50 -0700, Jan Beulich wrote: > > > > > On 12.02.16 at 10:37, wrote: > > > @@ -787,6 +788,16 @@ _csched_cpu_pick(const struct scheduler > > > *ops, > > > struct vcpu *vc, bool_t commit) > > > =C2=A0static int > > > =C2=A0csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc) > > > =C2=A0{ > > > +=C2=A0=C2=A0=C2=A0=C2=A0struct csched_vcpu *svc =3D CSCHED_VCPU(vc); > > > + > > > +=C2=A0=C2=A0=C2=A0=C2=A0/* > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* We have been called by vcpu_migrate(= ) (in schedule.c), as > > > part > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* of the process of seeing if vc can b= e migrated to another > > > pcpu. > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* We make a note about this in svc->fl= ags so that later, in > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* csched_vcpu_wake() (still called fro= m vcpu_migrate()) we > > > won't > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* get boosted, which we don't deserve = as we are "only" > > > migrating. > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*/ > > > +=C2=A0=C2=A0=C2=A0=C2=A0set_bit(CSCHED_FLAG_VCPU_MIGRATING, &svc->fl= ags); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return _csched_cpu_pick(ops, vc, 1); > > > =C2=A0} > >=20 > > I think you either want __set_bit() here or ... > >=20 > Yes, this is completely serialized by the vcpu's scheduler lock, so I > indeed want __set_bit(), sorry for the overlook. >=20 Which is indeed the case, in the case of this svc->flags, but not for other cases when svc->flags is used, for manipulating the other two existing flags (see, for instance be6507509454adf3bb5a50b9406c88504e996d5a "credit1: Use atomic bit operations for the flags structure"). So what I want is really the opposite of what I said above: set_bit() is ok, and I need the atomic test_and_clear(). -ENEEDMORECOFFEEATMORNING =C2=A0:-/ Thanks again 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) --=-9JTYczds3hiMP95QVa8k 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 v1 iEYEABECAAYFAla96T0ACgkQk4XaBE3IOsScUQCgh1JHOnDyLESBh0H8fBwUf6+D S88AoKN1EqePXHf92i+F/oUh+J9eKsFq =CABD -----END PGP SIGNATURE----- --=-9JTYczds3hiMP95QVa8k-- --===============4933280403418121342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4933280403418121342==--