[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 3 of 5 V2] libxl: make it possible to explicitly specify default sched params



On Tue, 2012-05-29 at 14:57 +0100, Ian Campbell wrote: 
> int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
> -                                libxl_sched_sedf_domain *scinfo)
> +                                libxl_domain_sched_params *scinfo)
>  {
> -    xc_domaininfo_t domaininfo;
> -    int rc;
> -
> -    rc = xc_domain_getinfolist(ctx->xch, domid, 1, &domaininfo);
> -    if (rc < 0) {
> -        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info list");
> +    uint64_t period;
> +    uint64_t slice;
> +    uint64_t latency;
> +    uint16_t extratime;
> +    uint16_t weight;
> +
> +    int ret;
> +
> +    ret = xc_sedf_domain_get(ctx->xch, domid, &period, &slice, &latency,
> +                            &extratime, &weight);
> +    if (ret != 0) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain sched sedf");
>          return ERROR_FAIL;
>      }
> -    if (rc != 1 || domaininfo.domain != domid)
> -        return ERROR_INVAL;
> -
> -
> -    rc = xc_sedf_domain_set(ctx->xch, domid, scinfo->period * 1000000,
> -                            scinfo->slice * 1000000, scinfo->latency * 
> 1000000,
> -                            scinfo->extratime, scinfo->weight);
> -    if ( rc < 0 ) {
> +
> +    if (scinfo->period != LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT)
> +        period = scinfo->period * 1000000;
> +    if (scinfo->slice != LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT)
> +        slice = scinfo->slice * 1000000;
> +    if (scinfo->latency != LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT)
> +        latency = scinfo->latency * 1000000;
> +    if (scinfo->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT)
> +        extratime = scinfo->extratime;
> +    if (scinfo->weight != LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT)
> +        weight = scinfo->weight;
> +
> +    ret = xc_sedf_domain_set(ctx->xch, domid, period, slice, latency,
> +                            extratime, weight);
>
I only tested this on your last version of this series (and I am still
trying to find the time to test this new one) and this wasn't working.
Reason should be the fact that the SEDF code in Xen wants you to put a
domain either in the "proper-EDF" state _or_ in the
"weighted-best-effort-state", and it discriminates this by checking
whether you're passing a slice+period _or_ a weight.

IOW, if your domain has a slice+period and wants a weight, either you
set slice and period to zero, or the whole thing will fail. In fact,
with this code, the new parameter set will include both the slice+period
(as the domain has them set) and the new weight that is being set by the
call... Does this sound right?

That's why the  current int main_sched_sedf(int argc, char **argv) is
doing this:

            if (opt_p) {
                scinfo.period = period;
                scinfo.weight = 0;
            }
            if (opt_s) {
                scinfo.slice = slice;
                scinfo.weight = 0;
            }
            if (opt_l)
                scinfo.latency = latency;
            if (opt_e)
                scinfo.extratime = extra;
            if (opt_w) {
                scinfo.weight = weight;
                scinfo.period = 0;
                scinfo.slice = 0;
            } 

That being said, I'm not sure at what level we want to enforce something
like the above. The lowest level toolstack seems fine to me, which would
mean putting something like the code above in the config file parsing...
If you agree, I'll try that and let you know whether or not it works.

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.