From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 1/4] sched: credit2: respect per-vcpu hard affinity Date: Thu, 23 Apr 2015 18:00:21 +0200 Message-ID: <1429804821.18926.199.camel@citrix.com> References: <1427363314-25430-1-git-send-email-jtweaver@hawaii.edu> <1427363314-25430-2-git-send-email-jtweaver@hawaii.edu> <551AB128.8090905@eu.citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4303048848302350592==" Return-path: In-Reply-To: <551AB128.8090905@eu.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: George Dunlap Cc: henric@hawaii.edu, "Justin T. Weaver" , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4303048848302350592== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xLhp4BvEOyE2M7t5mWQb" --=-xLhp4BvEOyE2M7t5mWQb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-03-31 at 15:37 +0100, George Dunlap wrote: > On 03/26/2015 09:48 AM, Justin T. Weaver wrote: > > --- a/xen/common/sched_credit2.c > > +++ b/xen/common/sched_credit2.c > > @@ -194,6 +195,12 @@ int opt_overload_balance_tolerance=3D-3; > > integer_param("credit2_balance_over", opt_overload_balance_tolerance); > > =20 > > /* > > + * Use this to avoid having too many cpumask_t structs on the stack > > + */ > > +static cpumask_t **scratch_mask =3D NULL; > > +#define csched2_cpumask scratch_mask[smp_processor_id()] >=20 > Since I'm asking for changes below: It's not clear to me when I'm > scanning the code that csched2_cpumask is a scratch variable. What > about calling the actual variable _scratch_cpumask and havind the > #define be scratch_cpumask? >=20 +1 > > /* Find the runqueue with the lowest instantaneous load */ > > for_each_cpu(i, &prv->active_queues) > > { > > struct csched2_runqueue_data *rqd; > > - s_time_t rqd_avgload; > > + s_time_t rqd_avgload =3D MAX_LOAD; > > =20 > > rqd =3D prv->rqd + i; > > =20 > > /* If checking a different runqueue, grab the lock, > > - * read the avg, and then release the lock. > > + * check hard affinity, read the avg, and then release the loc= k. > > * > > * If on our own runqueue, don't grab or release the lock; > > * but subtract our own load from the runqueue load to simulat= e > > - * impartiality */ > > + * impartiality. > > + * > > + * svc's hard affinity may have changed; this function is the > > + * credit 2 scheduler's first opportunity to react to the chan= ge, > > + * so it is possible here that svc does not have hard affinity > > + * with any of the pcpus of svc's currently assigned run queue= . > > + */ > > if ( rqd =3D=3D svc->rqd ) > > { > > - rqd_avgload =3D rqd->b_avgload - svc->avgload; > > + if ( cpumask_intersects(vc->cpu_hard_affinity, &rqd->activ= e) ) > > + rqd_avgload =3D rqd->b_avgload - svc->avgload; > > } > > else if ( spin_trylock(&rqd->lock) ) > > { > > - rqd_avgload =3D rqd->b_avgload; > > + if ( cpumask_intersects(vc->cpu_hard_affinity, &rqd->activ= e) ) > > + rqd_avgload =3D rqd->b_avgload; > > + > > spin_unlock(&rqd->lock); > > } > > else >=20 > Since we're already potentially falling through and doing the comparison > below with an unchanged rqd_avgload (which has now been set to MAX_LOAD > above), I wonder if it makes more sense to remove this "else continue" > here, just to avoid confusing people. > Agreed! It was me that suggested Justing how to reorg this block of code during v2's review... my bad not spotting that the 'else / continue' was useless then! :-P Regards, Dario --=-xLhp4BvEOyE2M7t5mWQb 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 iEYEABECAAYFAlU5FxUACgkQk4XaBE3IOsQkLQCgoC4AD261ugO3vqeJQW4QyRi2 snkAoJIccjjo2WEflqrqRIzWIwT1HApq =u5Ki -----END PGP SIGNATURE----- --=-xLhp4BvEOyE2M7t5mWQb-- --===============4303048848302350592== 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 --===============4303048848302350592==--