From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v1 3/4] libxl: add rt scheduler Date: Thu, 4 Sep 2014 15:51:33 +0100 Message-ID: <54087C75.8090907@eu.citrix.com> References: <1408921125-21470-1-git-send-email-mengxu@cis.upenn.edu> <1408921125-21470-4-git-send-email-mengxu@cis.upenn.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0657507078075990075==" 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: Meng Xu Cc: Ian Jackson , Ian Campbell , Sisu Xi , Stefano Stabellini , Dario Faggioli , Ian Jackson , "xen-devel@lists.xen.org" , Meng Xu , Jan Beulich , Chao Wang , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============0657507078075990075== Content-Type: multipart/alternative; boundary="------------080904000906090403070809" --------------080904000906090403070809 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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'll ping Ian Jackson to make sure he's OK with that. -George --------------080904000906090403070809 Content-Type: text/html; charset="utf-8" Content-Length: 6035 Content-Transfer-Encoding: quoted-printable
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.=C2=A0 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.=C2=A0 Internally, this will set all vcpus
to the same values.=C2=A0 This will allow us to check in a useable version
of the scheduler for people to test and improve.=C2=A0 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=3F

Meng / &c, does that sound reasonable=3F

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.);=C2=A0
But how about the get function=3F When users issue the command "xl sched-rt", how should we display the parameters of vcpus=3F We just give the "period", "budget" and "#VCPU" for a domain=3F 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"=3F 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.=C2=A0 For now, I think just make it print one budget / period for the domain; and we can change it later.

I'll ping Ian Jackson to make sure he's OK with that.

=C2=A0-George
--------------080904000906090403070809-- --===============0657507078075990075== 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 --===============0657507078075990075==--