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: 2996 bytes --]

[Adding RT-Xen people to the discussion, as well as Lars and Andrii from
GlobalLogic]

On mar, 2014-06-17 at 18:11 +0200, Dario Faggioli wrote:
> On lun, 2014-06-16 at 16:29 +0100, George Dunlap wrote:

> 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?
> 
Related to this, there are basically two groups of people working on
real-time scheduling:

 1) Josh and Robbie @ Dornerworks (+ Nate), working on fixing SEDF;

 2) RT-Xen developers, working at isolating the upstreamable bits of 
    RT-Xen itself (although they've not sent patches here in public
    yet).

The very nice part of 1) is that it (in the long run) fixes SEDF, and if
we are to keep it in the tree, I really think it should be fixed!

The very nice part of 2) is that it is already a more advanced and
mature real-time scheduling solution (for example, it already deals with
SMPs correctly, unlike current SEDF and Josh's RFC), but it really does
not have much to do with SEDF (either broken or fixed), both at an
interface and implementation (i.e., code sharing) points of view either.

So, again, depending on whether or not we want to keep SEDF, and how
hard we want for it's interface not only to compile, but to remain
meaningful, the way forward changes. That's why I'm asking what we want
to do with SEDF. :-/


Assuming that we *do* want to keep it, my personally preferred way to
proceed would be:
 - we take the implementation changes, but not the renaming, from Josh's
   effort
 - we merge the sched_sedf.c resulting from above with sched_rtglobal.c
   from RT-Xen, so to have a solution that works well on SMP systems 
   and also implements the existing SEDF interface

The merge can happen 'either way', i.e., we can try to borrow the global
scheduling bits (i.e., the SMP support) from RT-Xen's sched_rtglobal.c
into sched_sedf.c or, vice-versa, import Josh's SEDF/CBS code inside
sched_rtglobal.c... In either case, I'd need Josh and Meng, and their
respective fellows, to collaborate... Are you guys up for that? :-)

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