From mboxrd@z Thu Jan 1 00:00:00 1970 From: Meng Xu Subject: Re: [PATCH v1 3/4] libxl: add rt scheduler Date: Thu, 4 Sep 2014 12:12:29 -0400 Message-ID: References: <1408921125-21470-1-git-send-email-mengxu@cis.upenn.edu> <1408921125-21470-4-git-send-email-mengxu@cis.upenn.edu> <54087C75.8090907@eu.citrix.com> <1409845492.2673.240.camel@Solace.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7560576541215573465==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Jackson , Ian Campbell , Sisu Xi , Stefano Stabellini , Chenyang Lu , Dario Faggioli , Ian Jackson , "xen-devel@lists.xen.org" , Linh Thi Xuan Phan , Meng Xu , Jan Beulich , Chao Wang , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============7560576541215573465== Content-Type: multipart/alternative; boundary=089e0153689691add305023f9e1e --089e0153689691add305023f9e1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi George and Dario, 2014-09-04 11:55 GMT-04:00 George Dunlap : > On Thu, Sep 4, 2014 at 4:44 PM, Dario Faggioli > wrote: > > On gio, 2014-09-04 at 11:07 -0400, Meng Xu wrote: > > > >> 2014-09-04 10:51 GMT-04:00 George Dunlap > >> : > >> On 09/04/2014 03:47 PM, Meng Xu wrote: > >> > >> > Hi George, > >> > > >> > > >> > 2014-09-04 10:27 GMT-04:00 George Dunlap > >> > : > >> > On Wed, Sep 3, 2014 at 4:33 PM, George Dunlap > >> > 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). > =E2=80=8BI like the idea of adding "budget" because it's much clearer. =E2= =80=8B =E2=80=8BAs to other implementation details, I think I got it and will do t= hat now. :-)=E2=80=8B =E2=80=8BThanks, Meng=E2=80=8B --=20 ----------- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania --089e0153689691add305023f9e1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = George and Dario,


2014-09-04 11:55 GMT-04:00 George Dunlap <George.Dunla= p@eu.citrix.com>:
On T= hu, Sep 4, 2014 at 4:44 PM, Dario Faggioli
<dario.faggioli@citrix.com<= /a>> 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@e= u.citrix.com>:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 09/04/2014 03:47 PM, Meng Xu w= rote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi George,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 2014-09-04 10:27 GMT-04:00 G= eorge Dunlap
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> <George.Dunlap@eu.citrix.com>:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0On Wed, Sep 3, 2014 at 4:33 PM, George Dunlap
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<George.Dunlap@eu.c= itrix.com> wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0> While the domctl interface is not stable, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0libxl interface *is*
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0> stable, so we definitely need to think carefully
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0about what we want
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0> this to look like.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0> Let me give that a think. :-)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0OK, so we had a chat about this at our team meeting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0today, and here is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0what we came up with.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The feature freeze for 4.5 is next Wednesday.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The core scheduler is in good enough shape to be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0checked in as an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"experimental" mode, so it would be really nice to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0be able to get this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0checked in.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The DOMCTL interface isn't stable so we can change
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0that if we need to;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0however, the libxl interface *is* stable.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The current libxl scheduler parameter interface
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0assumes one set of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0parameters per domain; it's not yet setup for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0per-vcpu parameters.=C2=A0 It
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0is unlikely that we would be able to converge on a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0new interface by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0next week.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0So the suggestion was this: For the moment, use the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0existing libxl
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0interface on a per-domain basis.=C2=A0 Internally, this
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0will set all vcpus
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0to the same values.=C2=A0 This will allow us to check in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0a useable version
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0of the scheduler for people to test and improve.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Then for 4.6 we can
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0start working on a suitable libxl interface for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0setting per-vcpu
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0scheduling parameters.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Dario / Ian, did I miss anything?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Meng / &c, does that sound reasonable?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I have a question as to the = user interface.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> For 4.5, we only allow users= to set all vcpus to the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> values (I'm totally fine= with it.);
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> But how about the get functi= on? When users issue the command
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "xl sched-rt", how= should we display the parameters of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> vcpus? We just give the &quo= t;period", "budget" and "#VCPU" for a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> domain? I'm fine with th= is display for 4.5.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> However ,my concerns is: In = 4.6, when we allow vcpus to have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> different parameters and nee= d to display every vcpu's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> parameters, how should we di= splay when users use command "xl
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> sched-rt"? When vcpus h= ave different period and budget, we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> cannot display like what we = did in 4.5 then. :-(
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> It's just my thought, ju= st in case we neglect it. :-)
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think the xl interface doesn= 9;t have quite the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consistency guarantees as the lib= xl interface.=C2=A0 For now, I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0think just make it print one budg= et / period for the domain;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 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<= br> >> 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" fiel= d, since there's
already one there (for the SEDF scheduler).

We could re-use the "slice" field instead of adding "budget&= quot;, but I
think probably for clarity adding "budget" is better (although I&= #39;m
open to other opinions on that one).

=E2=80=8BI like the idea of= adding "budget" because it's much clearer. =E2=80=8B

=E2=80=8BA= s to other implementation details, I think I got it and will do that now. := -)=E2=80=8B

=E2=80=8BThanks,

Meng=E2=80=8B
--


-----------
Meng Xu
PhD = Student in Computer and Information Science
University of Pennsylvania
--089e0153689691add305023f9e1e-- --===============7560576541215573465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7560576541215573465==--