Re: [PATCH v2 2/5] libxl: enable per-VCPU extratime flag for RTDS

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

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

On Fri, 2017-09-01 at 12:03 -0400, Meng Xu wrote:
> On Fri, Sep 1, 2017 at 11:58 AM, Meng Xu <mengxu@cis.upenn.edu>
> wrote:
> > @@ -705,6 +717,12 @@ static int sched_rtds_domain_set(libxl__gc
> > *gc, uint32_t domid,
> >          sdom.period = scinfo->period;
> >      if (scinfo->budget != LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT)
> >          sdom.budget = scinfo->budget;
> > +    if (scinfo->extratime !=
> > LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT) {
> > +        if (scinfo->extratime)
> > +            sdom.flags |= XEN_DOMCTL_SCHEDRT_extra;
> > +        else
> > +            sdom.flags &= ~XEN_DOMCTL_SCHEDRT_extra;
> > +    }
> >      if (sched_rtds_validate_params(gc, sdom.period, sdom.budget))
> >          return ERROR_INVAL;
> 
> 
> As you mentioned in the comment to the xl patch v1, I used
> LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT for extratime flag as what
> we did for period and budget. But the way we handle flags is exactly
> the same with the way we handle period and budget.
> 
Mmm... and (since you say 'But') is that a problem?

> I'm ok with what it is in this patch, although I feel that we can
> kill the
>  if (scinfo->extratime != LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT)
> because LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT is -1.
> 
No, sorry, I don't understand what you mean here...

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

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

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

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