Re: [Xen-devel] [PATCH v4] xen: sched_rt: print useful affinity info when dumping

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2015-05-12 at 12:01 -0400, Meng Xu wrote:
> Hi Dario,
> 
Hi,

> 2015-05-12 10:06 GMT-04:00 Dario Faggioli <dario.faggioli@xxxxxxxxxx>:

> > --- 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()]
> 
> 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?
> 
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

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel