[Xen-devel] Plans for the SEDF scheduler

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

Hi everyone,

I've copied the committers, Lars as community manager, Wei as the
release manager, George as the scheduler maintainer, RT-Xen and
DornerWorks people, which have some interest in the field, I believe.
Please, widen the crowd if you think it's necessary/best.

Straight to the point: the SEDF scheduler code is in a rather bad state:

 * it is buggy (tests are failing since... well, at least since when I
   joined the community, 3 years ago!). Basically, it was not designed
   with host and guest SMP support in mind, and has never been updated;

 * it is not used. Well, that's hard to tell, of course, but I really
   really expect that to be the case.

 * it is useless as:
    - it tries to be a general purpose scheduler, but we have Credit
      (and, soon enough, hopefully, Credit2) for that
    - for real-time we have ARINC653 (super-hard real-time), maintained
      and supported, and RTDS (hard/soft real-time), actively
      developed.

For these reasons, I think we should get rid of it. Actually, I've
discovered that this was the plan in 2006 already:  :-)

 git show db51cd09d37ea44b126bb259f9392248afd768e6
 ...
 diff --git a/docs/src/interface.tex b/docs/src/interface.tex
 index c9017c7..9a59840 100644
 --- a/docs/src/interface.tex
 +++ b/docs/src/interface.tex
 @@ -209,8 +209,8 @@ implement timeout values when they block.
 
  Xen offers a uniform API for CPU schedulers.  It is possible to choose
  from a number of schedulers at boot and it should be easy to add more.
 -The SEDF, BVT, and Credit schedulers are part of the normal Xen
 -distribution.  BVT and SEDF will be going away and their use should be
 +The SEDF and Credit schedulers are part of the normal Xen
 +distribution.  SEDF will be going away and its use should be
  avoided once the credit scheduler has stabilized and become the default.
  The Credit scheduler provides proportional fair shares of the
  host's CPUs to the running domains. It does this while transparently

I'm up for sending a series to that effect, but I'd be interested in
your opinion on what's the best way to do so.

Looking at the commit referred above, it seems like a scheduler can just
disappear which, as far as Xen and libxc are concerned, does seem ok to
me. Is that so?

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?

About domain_sched_params:

 libxl_domain_sched_params = Struct("domain_sched_params",[
     ("sched",        libxl_scheduler),
     ("weight",       integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_WEIGHT_DEFAULT'}),
     ("cap",          integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_CAP_DEFAULT'}),
     ("period",       integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_PERIOD_DEFAULT'}),
     ("slice",        integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_SLICE_DEFAULT'}),
     ("latency",      integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_LATENCY_DEFAULT'}),
     ("extratime",    integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_EXTRATIME_DEFAULT'}),
     ("budget",       integer, {'init_val': 
'LIBXL_DOMAIN_SCHED_PARAM_BUDGET_DEFAULT'}),
     ])

SEDF now uses 'weight', 'period', 'slice', 'latency' and 'extratime'. If
considering option 3, RTDS:
 - does not use 'weight' right now, but we can use it as an alternative
   way to set 'budget', which is not far from the way SEDF uses it;
 - uses 'period';
 - does not use 'slice', but that is just a synonym for 'budget';
 - does not use 'latency' right now; we can use it as an alternative way
   to set 'period', but that would be a bit different from what SEDF
   does with it;
 - does not use 'extratime' for now, but will, at some point, in a very
   similar way to how SEDF uses it.

Oh and, whatever route we decide to go for, is it perhaps necessary that
we do something like deprecate it for one release (4.6), e.g., by
printing a warning saying that <<SEDF is still here now, but is
deprecated and you won't find it in the next release>>, and then do the
actual removal/conversion in 4.7?

Let me know what you think.

Thanks and Regards,
Dario

Attachment: signature.asc
Description: This is a digitally signed message part

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