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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Fri, 2017-08-04 at 15:34 +0100, Wei Liu wrote:
> On Fri, Aug 04, 2017 at 02:53:51PM +0200, Dario Faggioli wrote:
> > 
> > Well, I guess yes. But how does this matter? Each scheduler can, if
> > it
> > wants, use all these parameters in the way it actuallly prefers.
> > So,
> > the fact that RTDS will be using 'extratime' for letting vCPUs
> > execute
> > past their own real-time reservation, does not prevent the
> > reintroduced
> > SEDF --nor any other already existing or new scheduler-- to also
> > use
> > it, for similar (or maybe even not so similar) purposes.
> > 
> > Or am I missing something?
> 
> If extratime means different things to different schedulers, it's
> going
> to be confusing. As a layperson I can't tell what extratime is or how
> it
> is supposed to be used. I would like to have the field to have only
> one
> meaning.
>
Well, I do see what you mean, but then I don't understand why we have
the data structure organized like this, i.e., with all the parameters
for all the schedulers in the same struct.

IAC:
- extratime was only used by SEDF
- SEDF is not coming back, at least not in the form it had when it was
removed, because it was bitrotten and buggy, and RTDS has actually
replaced it
- if a correct version of SEDF would ever come back, and live alongside
with RTDS, both the schedulers would use extratime to mean the same
(although, of course, actual use and implementation may vary)

This should be enough to address your concerns. Let me know if it's
not. :-)

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: signature.asc
Description: This is a digitally signed message part

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