Re: [Xen-devel] [Xen-users] xl doesn't honour the parameter cpu_weight from my config file while xm does honour it

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-04-24 at 15:33 +0100, Dieter Bloms wrote:
> Hi,
> 
> On Tue, Apr 24, Ian Campbell wrote:
> 
> > I think you mean cpu_weight rather than cpu-weight.
> 
> yes of course, fixed.
> 
> > =item B<latency=N>
> > 
> > I think you missed the value here.
> 
> I don't know the value for it, so I added N as you suggested.
> 
> > > +    ("us", KeyedUnion(None, libxl_scheduler, "sched",
> > > +                 [("credit", libxl_sched_credit_domain),
> > > +                 ("credit2", libxl_sched_credit2_domain),
> > > +                 ("sedf", libxl_sched_sedf_domain),
> > > +                 ("arinc653", libxl_sched_arinc653_domain),
> > > +                 ], keyvar_init_val = "-1")),
> > 
> > I don't think a KeyedUnion is right here, since the user of libxl
> > doesn't really have a choice about which scheduler is in user (that's
> > set at boot time or via cpupool interfaces).
> > 
> > You could use a Union, but below I'll make an argument that perhaps a
> > Struct would be better.
> 
> Hm, but when I don't use a union with the structure for each scheduler I
> have to create a structure depend of scheduler at runtime, because the
> functions libxl_sched_XXXXXX_domain_set use there own structure for
> their scheduler.

I mean create a single struct with all of the options in it, from which
libxl will select the appropriate set of parameters (much like the code
you have now does. You don't need to decide the content of that struct
at runtime.

The IDL patch is below, other than changing "us" to "sched_params" I
think most of the rest of your patch remains the same.

> I've create a new function libxl__sched_set_params, which set the params
> depend on the scheduler as you suggested.
> 
> I'am not a software developer, so please be forbear with me.

That's ok, thanks for doing this!

You add a struct for arinc635 but don't actually do anything with it,
you may as well leave it out for now?

Ian.


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