Re: [RFC PATCH 3/4] Updated comments/variables to reflect cbs, fixed formatting and confusing comments/variables

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

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

On lun, 2014-06-16 at 16:29 +0100, George Dunlap wrote:
> On 06/16/2014 10:33 AM, Jan Beulich wrote:
> >>>> On 13.06.14 at 21:58, <josh.whitehead@dornerworks.com> wrote:
> >> --- a/xen/include/public/trace.h
> >> +++ b/xen/include/public/trace.h
> >> @@ -75,7 +75,7 @@
> >>   /* Per-scheduler IDs, to identify scheduler specific events */
> >>   #define TRC_SCHED_CSCHED   0
> >>   #define TRC_SCHED_CSCHED2  1
> >> -#define TRC_SCHED_SEDF     2
> >> +#define TRC_SCHED_CBS      2
> > While the change to domctl.h is fine, I'm not sure we can allow simple
> > renaming elsewhere in the public headers (i.e. the old name may need
> > to remain there, guarded with a __XEN_INTERFACE_VERSION__
> > conditional).
> 
> I think the tracing stuff is fine too -- we've always considered that 
> non-stable (and have made incompatible changes across versions).
> 
> But the libxl interfaces *do* need to have something sensible done with 
> them.
> 
> Given that,  I think it would probably be better to make this patch series:
> 
> 1/N: Add sched_cbs.c to Xen
> 2/N: Add cbs to toolstack
> 3/N: Remove sedf scheduler (with appropriate backwards-compatibility bits)
> 
> I think that would make it a bit easier to review as well.
> 
As far as this patch is concerned, I agree with George.

However... Is removing SEDF an option? Is radically changing, if not
it's behavior (as it's known to be pretty broken), the expectations of
an user, e.g., of an old application being compiled with a new version
of xen+libxl an option?

If yes, what's the process to do that?

Personally, I'm all for having a really working real-time scheduling
solution, and you all know that. :-) However, especially considering
Josh's and Robbie's series, I think I would not remove or rename SEDF, I
rather "just" amend the implementation.

In future, it would be interesting to introduce more advanced real-time
scheduling features an capabilities, like the ones coming from RT-Xen
(and the RT-Xen guys are working on doing that), but I think that can be
done step-by-step, and without any massive renaming or removal.

So, I'm asking, mostly to George, about the overall scheduling aspects
and implications, and to the tools maintainer, as that's where API
stability is to be enforced: should this be a concern? In what sense API
stability applies here? Can we, for example, start to ignore one or more
SEDF scheduling parameters?

I'm asking explicitly about the parameters because, although I think
that most of the changes in this series does not actually call for much
renaming, at least the 'weight' and, to certain extent the 'extra',
parameters are a bit difficult to deal with (mostly because they're a
remnant from when SEDF was meant as a general purpose scheduler too!).

Thoughts?

Thanks and 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: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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