Re: [PATCH v1 3/4] libxl: add rt scheduler

[Meng Xu <xumengpanda@gmail.com>]

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

Hi George and Dario,


2014-09-04 11:55 GMT-04:00 George Dunlap <George.Dunlap@eu.citrix.com>:

> On Thu, Sep 4, 2014 at 4:44 PM, Dario Faggioli
> <dario.faggioli@citrix.com> wrote:
> > On gio, 2014-09-04 at 11:07 -0400, Meng Xu wrote:
> >
> >> 2014-09-04 10:51 GMT-04:00 George Dunlap
> >> <george.dunlap@eu.citrix.com>:
> >>         On 09/04/2014 03:47 PM, Meng Xu wrote:
> >>
> >>         > Hi George,
> >>         >
> >>         >
> >>         > 2014-09-04 10:27 GMT-04:00 George Dunlap
> >>         > <George.Dunlap@eu.citrix.com>:
> >>         >         On Wed, Sep 3, 2014 at 4:33 PM, George Dunlap
> >>         >         <George.Dunlap@eu.citrix.com> wrote:
> >>         >         >
> >>         >         > While the domctl interface is not stable, the
> >>         >         libxl interface *is*
> >>         >         > stable, so we definitely need to think carefully
> >>         >         about what we want
> >>         >         > this to look like.
> >>         >         >
> >>         >         > Let me give that a think. :-)
> >>         >
> >>         >
> >>         >         OK, so we had a chat about this at our team meeting
> >>         >         today, and here is
> >>         >         what we came up with.
> >>         >
> >>         >         The feature freeze for 4.5 is next Wednesday.
> >>         >
> >>         >         The core scheduler is in good enough shape to be
> >>         >         checked in as an
> >>         >         "experimental" mode, so it would be really nice to
> >>         >         be able to get this
> >>         >         checked in.
> >>         >
> >>         >         The DOMCTL interface isn't stable so we can change
> >>         >         that if we need to;
> >>         >         however, the libxl interface *is* stable.
> >>         >
> >>         >         The current libxl scheduler parameter interface
> >>         >         assumes one set of
> >>         >         parameters per domain; it's not yet setup for
> >>         >         per-vcpu parameters.  It
> >>         >         is unlikely that we would be able to converge on a
> >>         >         new interface by
> >>         >         next week.
> >>         >
> >>         >         So the suggestion was this: For the moment, use the
> >>         >         existing libxl
> >>         >         interface on a per-domain basis.  Internally, this
> >>         >         will set all vcpus
> >>         >         to the same values.  This will allow us to check in
> >>         >         a useable version
> >>         >         of the scheduler for people to test and improve.
> >>         >         Then for 4.6 we can
> >>         >         start working on a suitable libxl interface for
> >>         >         setting per-vcpu
> >>         >         scheduling parameters.
> >>         >
> >>         >         Dario / Ian, did I miss anything?
> >>         >
> >>         >         Meng / &c, does that sound reasonable?
> >>         >
> >>         >
> >>         > I have a question as to the user interface.
> >>         > For 4.5, we only allow users to set all vcpus to the same
> >>         > values (I'm totally fine with it.);
> >>         > But how about the get function? When users issue the command
> >>         > "xl sched-rt", how should we display the parameters of
> >>         > vcpus? We just give the "period", "budget" and "#VCPU" for a
> >>         > domain? I'm fine with this display for 4.5.
> >>         >
> >>         >
> >>         > However ,my concerns is: In 4.6, when we allow vcpus to have
> >>         > different parameters and need to display every vcpu's
> >>         > parameters, how should we display when users use command "xl
> >>         > sched-rt"? When vcpus have different period and budget, we
> >>         > cannot display like what we did in 4.5 then. :-(
> >>         >
> >>         >
> >>         > It's just my thought, just in case we neglect it. :-)
> >>
> >>
> >>         I think the xl interface doesn't have quite the same
> >>         consistency guarantees as the libxl interface.  For now, I
> >>         think just make it print one budget / period for the domain;
> >>         and we can change it later.
> >>
> >>
> >>
> >>
> >> I see. I'm totally ok with the decision! :-)
> >> So I will only use the existing libxl interface without adding an
> >> array to it, to set/get the vcpus' parameters of a domain. Am I right?
> >>
> > Yep, no array. You just add a 'period' and a 'budget' fields _inside_
> > libxl_domain_sched_params, without putting them inside any wrapping
> > struct, union or array.
>
> Except that you don't need to add a "period" field, since there's
> already one there (for the SEDF scheduler).
>
> We could re-use the "slice" field instead of adding "budget", but I
> think probably for clarity adding "budget" is better (although I'm
> open to other opinions on that one).
>

​I like the idea of adding "budget" because it's much clearer. ​

​As to other implementation details, I think I got it and will do that now.
:-)​

​Thanks,

Meng​

-- 


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

[-- Attachment #1.2: Type: text/html, Size: 8095 bytes --]

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

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