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

[Joshua Whitehead <josh.whitehead@xxxxxxxxxxxxxxx>]

On 6/17/2014 12:11 PM, Dario Faggioli wrote:
> 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@xxxxxxxxxxxxxxx> 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.
>
I'll let George comment on this again, but it sounds like from his e-mails that
removing SEDF isn't *that* big of a problem, however as discussed elsewhere,
keeping the name and changing the "guts" of it sounds like a better option.

> 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.
> 
This is another point for splitting the patch as we discussed in the earlier
e-mail.  Having that separation would give us more flexibility in perhaps
merging and splicing in functionality from others if desired.  We haven't had
the chance to fully review the stuff from Meng/RT-Xen, so we'll have to see
what's applicable, but that could certainly be an option.  If we upstream this
patch series it should be relatively easy to then incrementally add features
from other sources over time and for DornerWorks to maintain the scheduler in
the future.

> 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!).
> 
Just a quick comment on this - our view of the changes to SEDF is to return it
to something that's suitable for real-time applications which almost by
definition makes it unsuitable as a general purpose scheduler, it was the
conversion to general purpose that made SEDF so ugly in the first place.  So
there may be things about our changes that may cause problems for someone trying
to run a normal computer on SEDF but make perfect sense in the
embedded/real-time world. Thanks,

- Josh Whitehead

> Thoughts?
> 
> Thanks and Regards,
> Dario
> 


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