Re: [PATCH v1 4/4] xl: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1716 bytes --]

On Thu, 2015-05-14 at 10:24 -0400, Meng Xu wrote:
> > @@ -5744,6 +5749,7 @@ static int sched_rtds_pool_output(uint32_t poolid)
> >      return 0;
> >  }
> >
> > +
> >  static int sched_default_pool_output(uint32_t poolid)
> >  {
> >      char *poolname;
> > @@ -6120,38 +6126,87 @@ int main_sched_rtds(int argc, char **argv)
> >  {
> >      const char *dom = NULL;
> >      const char *cpupool = NULL;
> > -    int period = 0; /* period is in microsecond */
> > -    int budget = 0; /* budget is in microsecond */
> > +
> > +    int vcpus[LIBXL_XEN_LEGACY_MAX_VCPUS]; /* indices of VCPUs that change */
> > +    int periods[LIBXL_XEN_LEGACY_MAX_VCPUS]; /* period is in microsecond */
> > +    int budgets[LIBXL_XEN_LEGACY_MAX_VCPUS]; /* budget is in microsecond */
> 
> 
> We know this is not good (ugly), but not sure about the best approach
> to do this. Basically, if users tries to input several pairs of period
> and budget, what is the best way to hold those data? Should we just
> increase the array size by using something like remalloc when we find
> more parameters are inputted?
> 
In xl and/or libxl, a couple of remalloc() are not a problem. there are
very few hot paths in them, and this is certainly not one of them.

In xl, we have xrealloc() defined for that purpose, in libxl,
GCNEW_ARRAY() and GCREALLOC_ARRAY(), so really, no big deal. It may
might sense to put think at something to avoid realloc()-ing 17 times by
1 element (like doubling the allocation at each time, and then, of
course, only use the actually filled elements).

In any case, the problem here is not (only) the static array, it is the
use of LIBXL_XEN_LEGACY_MAX_VCPUS.

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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