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

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

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

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@citrix.com> 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.

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.

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. :-)

Regards,
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