[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

[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



Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.