Re: [Xen-devel] Test result of xen-unstable changeset 25249

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-04-27 at 16:20 +0100, Dario Faggioli wrote:
> On Fri, 2012-04-27 at 10:08 +0100, Ian Campbell wrote: 
> > > I think what we really want to do is is any of the parameters are set, 
> > > after the domain is first created, to read the scheduling parameters for 
> > > the domain (which will be the defaults), change the ones that are set in 
> > > the config file, and then write the whole structure back.  That 
> > > shouldn't be too hard, as libxl__sched_set_params() is called after the 
> > > domain itself is created;
> > 
> > I guess the low level libxl_sched_*_params_set should take care of this?
> > 
> Possibly, but there's more I'm not sure I understand in the patch (the
> original patch, the one that has been checked-in on Wednesday):
> 
> +int libxl__sched_set_params(libxl__gc *gc, uint32_t domid, 
> libxl_sched_params *scparams)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    libxl_scheduler sched;
> +    libxl_sched_sedf_domain sedf_info;
> +    libxl_sched_credit_domain credit_info;
> +    libxl_sched_credit2_domain credit2_info;
> +    int ret;
> +
> +    sched = libxl_get_scheduler (ctx);
> +    switch (sched) {
> +    case LIBXL_SCHEDULER_SEDF:
> +      sedf_info.period = scparams->period;
> +      sedf_info.slice = scparams->slice;
> +      sedf_info.latency = scparams->latency;
> +      sedf_info.extratime = scparams->extratime;
> +      sedf_info.weight = scparams->weight;
> +      ret=libxl_sched_sedf_domain_set(ctx, domid, &sedf_info);
> +      break;
> +    case LIBXL_SCHEDULER_CREDIT:
> +      credit_info.weight = scparams->weight;
> <snip>
> 
> sched gets the return value of libxl_get_scheduler() which, if I'm not
> wrong , read the "default" xen scheduler for this boot, i.e., the one
> specified by the "sched=" boot command line or whatever the default for
> that is (credit1).
> 
> After that it decides what libxl_sched_*_domain_set() to call basing
> right on that value. What I'm missing is what prevents the domain in
> question to be part of a cpupool (e.g., by specifying "poolid=" in its
> config file as well) for which the scheduler is a different one.
> 
> It seems to me that, in such case, we will be setting the wrong set of
> parameters anyway, independently on how well we manage in putting a
> default in place for them... Am I missing something? If not, as I
> haven't found any way of finding out what scheduler is actually being
> used for a specific domain, shouldn't we add or mimic that (going
> through cpupool, perhaps, I haven't checked yet)?

I think you are right. Should we have libxl_gfet_domain_scheduler (or
some such) which implements the appropriate logic?

Ian.


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