Re: [Xen-devel] Plans for the SEDF scheduler

[Meng Xu <xumengpanda@xxxxxxxxx>]

[Add Chong and Dagaen who is working on improving RTDS scheduler now.]
> I'm less sure of libxl, because of the API stability claims. It looks
> like this is all about (as there are not scheduler specific API
> functions, which is good) this:
>
>  # Consistent with values defined in domctl.h
>  # Except unknown which we have made up
>  libxl_scheduler = Enumeration("scheduler", [
>      (0, "unknown"),
>      (4, "sedf"),
>      (5, "credit"),
>      (6, "credit2"),
>      (7, "arinc653"),
>      (8, "rtds"),
>      ])
>
> The solutions I see are:
>  1. get rid of the field. This does not sound ideal from an API
>     stability point of view;
>  2. keep the field 'physically', but return warnings and errors when it
>     is used. This is a change in behavior, so also not really stable
>     (but, hey, the scheduler is going away, the behavior will change,
>     one way or another!)
>  3. RTDS has a really similar interface and, to a certain extent, a
>     similar behavior too. Would it make sense to, upon suitable
>     warnings, of course, convert the requests within libxl, i.e.,
>     when someone asks for SEDF, we give him RTDS?
>
> Honestly, I'd prefer 2, and I don't much like 3. However, it really
> seems that 3 gives us a way to keep most of our promises about API
> stability... Thoughts?

I think option 2) is better than the other two choices. The SEDF does
not use a strictly EDF scheduling policy as RTDS does, so the
scheduling sequence of VCPUs won't be same even when we tuned RTDS to
single-core EDF scheduler. This implicit transformation may give users
more difficulty to figure out how to use the real time scheduler in
Xen.

Thanks,

Meng


-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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