From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v4] xen: sched_rt: print useful affinity info when dumping Date: Tue, 12 May 2015 18:39:17 +0200 Message-ID: <1431448757.2978.71.camel@citrix.com> References: <20150512140601.31582.72317.stgit@Solace.station> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6422929479673073750==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Meng Xu Cc: George Dunlap , Keir Fraser , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============6422929479673073750== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UqZc0SyJB5k2IoJ9HSid" --=-UqZc0SyJB5k2IoJ9HSid Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-12 at 12:01 -0400, Meng Xu wrote: > Hi Dario, >=20 Hi, > 2015-05-12 10:06 GMT-04:00 Dario Faggioli : > > --- a/xen/common/sched_rt.c > > +++ b/xen/common/sched_rt.c > > @@ -124,6 +124,24 @@ > > #define TRC_RTDS_BUDGET_REPLENISH TRC_SCHED_CLASS_EVT(RTDS, 4) > > #define TRC_RTDS_SCHED_TASKLET TRC_SCHED_CLASS_EVT(RTDS, 5) > > > > + /* > > + * Useful to avoid too many cpumask_var_t on the stack. > > + */ > > +static cpumask_t **_cpumask_scratch; > > +#define cpumask_scratch _cpumask_scratch[smp_processor_id()] >=20 > The cpumask_scratch seems never used in this patch.. Did I miss anything? > No, it's never used, because, as it happens, the use case this patch deals with needs to explicitly reference the _cpumask_scratch array. That should be the exception rather than the rule, and the reason why it is necessary this time is given in the comments. > If it's not used in any other places, do we really need this #define? >=20 We do, IMO. The changelog says that, in addition to improving the dump output, this change puts in place a "scratch cpumask machinery", useful to reduce the use of either on stack or dynamically allocated cpumask-s. That #define is part of the machinery, as it is what people should use everywhere (possible), to reference the scratch bitmap. So, let me ask a question myself: when can we expect a patch that takes advantage of the scratch cpumask machinery being introduced here, in order to get rid of some (most, hopefully) of the cpumask_t and cpumask_var_t all around sched_rt.c? :-D When that will happen, you'll need that #define, and if I kill it from here, you'll have to introduce it yourself. As said, I like it being introduced here better, but can live with you adding it with your patch(es), if that's what everyone else prefer. Regards, Dario --=-UqZc0SyJB5k2IoJ9HSid 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 iEYEABECAAYFAlVSLLYACgkQk4XaBE3IOsSEYACfVx+maLkJT1BUv8Npfe17ots5 +LAAoKKwBlpPQW01F2XOl/G2jcs6jqe4 =B8uG -----END PGP SIGNATURE----- --=-UqZc0SyJB5k2IoJ9HSid-- --===============6422929479673073750== 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 --===============6422929479673073750==--