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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On gio, 2014-06-26 at 17:23 -0400, Joshua Whitehead wrote:
> On 6/17/2014 12:11 PM, Dario Faggioli wrote:

> > 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.
> 
Indeed.

> > 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.
> 
I wanted to re-review and look as close as possible to both your and
RT-Xen's guys' series, but couldn't today. I'll do this on Monday, and
let you know what my feeling is about what we should use as a basis and
what should be added on top of that incrementally.

> > 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.
>
I have no intention to keep/make SEDF suitable for GP scheduling. I'm
well aware of the different needs of the two domains (RT and non-RT)
and, in general, I'm no fan of "one scheduler to rule them all"
approach, as you may well end up in making everyone really unhappy about
the service they get.

That being said, there are two reasons for my comments above. For one,
have a look at what Linus Torvalds usually says about kernel changes
that breaks userspace. Sure, we are not Linux, sure SEDF is already
broken, etc., but still I don't think it's nice to completely subvert
some user's world (provided there are any users, which may be false, I
have to admit). As George said, not breaking the compilation at libxl
level is something we really must do. About the functionality, I was not
so sure. I'm not so sure yet, but I guess I fundamentally concur with
him.

On a completely different perspective, as I at least partially already
pointed out, 'extra' really looks very similar to your soft to me, and
for 'weight', since we're talking about CBS, ever heard of GRUB (not the
bootloader: Greedy Reclaiming of Unused Bandwidth) and its further
evolution SHRUB. they both are enhanced version of the CBS, where a
weight may come handy. Of course, I'm not suggesting rushing to
implement those right away, I was just wondering what would be best
done, from an interface point of view right now, knowing that we may get
to it (i.e., to use 'weight' back, and in a very similar way, _without_
turning back SEDF into a non-RT scheduler!).

Anyway, there are more pressing decisions to make right now, I
think. :-)

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
http://lists.xen.org/xen-devel