Re: [Xen-devel] [PATCH RFC v1 2/3] libxl: enable per-VCPU work conserving flag for RTDS

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Aug 04, 2017 at 10:13:18AM +0200, Dario Faggioli wrote:
> On Thu, 2017-08-03 at 17:39 -0400, Meng Xu wrote:
> > On Thu, Aug 3, 2017 at 11:53 AM, Dario Faggioli
> > <dario.faggioli@xxxxxxxxxx> wrote:
> > > 
> > > How about, here at libxl level, we use the "extratime" field that
> > > we
> > > have as a leftover from SEDF (and which had, in that scheduler, a
> > > similar meaning)?
> > > 
> > > If we don't want to use that one, and we want a new field, I
> > > suggest
> > > thinking to a shorter name.
> > 
> > How about 'LIBXL_DOMAIN_SCHED_PARAM_FLAG'?
> > We use a bit in the flag field in the sched_rt.c to indicate if a
> > VCPU
> > is work-conserving. 
> >
> This is entirely in the hands of tools maintainers, especially
> considering this is the libxl API.
> 
> In general, yes, for the same reasons I suggested using flags in both
> Xen interface and implementation, I also like using flags here. 
> 
> *HOWEVER*, in this case, we do have that 'extratime' field already, as
> a leftover from SEDF, which is there taking space and cluttering the
> interface, so why don't make good use of it. Especially considering it
> was used for _exactly_ the same thing, and with _exactly_ the same
> meaning, and even for a very similar (i.e., SEDF was also real-time)
> kind of scheduler.

Correct me if I'm wrong:

1. extratime is ever only used in SEDF
2. SEDF is removed

That means we do have extratime to use in all other schedulers.

However, please consider the possibility of reintroducing SEDF in the
future. Suppose that would happen, does extratime still has the same
semantics?

> 
> Also, note that Xen interface and libxl API are different, and the same
> concepts, does not necessarily have to be used in lockstep. It may or
> may not be the best/easies/whatever thing to actually do, but on a case
> by case basis.
> 

Indeed.

> IAC, final say is Wei's and Ian's, and although I do have a preference,
> which I voiced, I'm totally fine with whichever between the two
> approaches they advise us to take. :-)
> 

I will leave this to you two to decide. I don't think I have an opinion
here as long as the things I mentioned above are taken into
consideration.

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