Xen devel - Nov 2006 - Question on xen schedulers

All,
 
i had sent the mail below to xen-user mailing list before, but not got any
helpful reaction. Probably it is really more a question for the xen-devel list;
i would appreciate any useful  info on this topic:
 
''credit'' is now the (only) recommended scheduler and the
others (''bvt'', ''sedf'') are already removed
from the latest Xen 3.0 sources or will be removed in the future.
Now, ''credit'' is designed for an optimum utilisation of a SMP
system and may be really the best scheduler for this purpose. But i think this
is not the only useful scenario for the usage of Xen; there maybe other
scenarios with other demands, e.g. ''soft'' real-time systems
and/or single processor systems.
If i remember correctly, one of the major advantages mentioned in the first
announcements of Xen 3.0 was the support of multiple schedulers (for different
purposes). Could give anyone the reasons why this approach is not longer valid
and what is the reason to kick out the already existing more ''real-time
friendly'' schedulers, especially sedf ?
 
Thanks
 
Werner 


 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 15/11/06 4:48 pm, "Schmidt Werner"
<Werner.Schmidt@avaya.tenovis.com>
wrote:
> ''credit'' is now the (only) recommended scheduler and the
others (''bvt'',
> ''sedf'') are already removed from the latest Xen 3.0
sources or will be removed
> in the future.
> Now, ''credit'' is designed for an optimum utilisation of a
SMP system and may
> be really the best scheduler for this purpose. But i think this is not the
> only useful scenario for the usage of Xen; there maybe other scenarios with
> other demands, e.g. ''soft'' real-time systems and/or
single processor systems.
> If i remember correctly, one of the major advantages mentioned in the first
> announcements of Xen 3.0 was the support of multiple schedulers (for
different
> purposes). Could give anyone the reasons why this approach is not longer
valid
> and what is the reason to kick out the already existing more
''real-time
> friendly'' schedulers, especially sedf ?
The main reason is that noone has time to support them and they are buggy.
If there is demand for SEDF then we may keep it in the tree, but unless
someone steps up to maintain it then bugs will not be fixed (for example, it
exhibits weird behaviours with some settings of the scheduling parameters).
However I understand this may not matter for users who have found reasonable
parameter settings which work for them.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Nov 15, 2006 at 05:48:39PM +0100, Schmidt Werner
wrote:
>    Now, ''credit'' is designed for an optimum utilisation
of a SMP system and
>    may be really the best scheduler for this purpose. But i think this is
not
>    the only useful scenario for the usage of Xen; there maybe other
scenarios
>    with other demands, e.g. ''soft'' real-time systems
and/or single processor
>    systems.
Hi.

Just to clarify, the credit CPU scheduler is designed with a
couple of goals in mind, not all of which have to do with
multi-processing:

1- Comparative weighted fairness among competing guests
    By default, all guests are equal. By increasing/decreasing
    a guest''s weight compared to others, it can be made more/less
    important. This has effects on UP as well as SMP hosts.

2- Automatic preemption of CPU intensive guests by I/O generating ones
    Guests that sleep/wake frequently and do not consume their
    fair share of CPU resources will preempt CPU intensive domains
    automatically. The administrator will not need to tag domains as
    CPU intensive or I/O generating to achieve this result. Again,
    this feature is targeted at both UP and SMP hosts.

3- Work conserving on SMP systems
    No CPU shall ever go idle if there is runnable work. Load balancing
    is automatic and fine grain.


The credit scheduler attempts to solve common problems without
administrator involvement. Common problems targeted include:
- Scheduling competing I/O and CPU intensive domains.
- Load balancing VCPUs on an SMP system (My grandmother has an SMP
  desktop. Let''s face it: this is a common scenario now).

I agree soft real time scheduling methods can also be useful to solve
other problems. I think it would be useful for people to explain what
problems they would like to solve so we can support the right type of
soft real time features to address them.

Would single processor strict priority scheduling solve most problems
people care about?

Are there scenarios where better per guest wake-to-run latency or CPU
reservations guarantees are required? What are they?

There is lots of work to do and lots of code to maintain. It would be
smart to prioritize things a bit. I think it would be useful to build
some concensus in the community with respect to this. Your post is a
good starting point. So, what scenarios do people out there care about?

Cheers,
Emmanuel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Emmanuel asked:

 >So, what scenarios do people out there care about?


We''d like to see Xen continue to support pluggable schedulers. If the 
default scheduler continues to work through the pluggable interface, 
then people who want more esoteric scheduling can write and plug in 
their own conforming scheduler. Esoteric schedulers don''t have to be 
part of the Xen source tree. No one else has to maintain the esoteric 
schedulers and they are isolated from major changes by conforming to the 
pluggable scheduler interface. If someone else does want to reuse or 
build on some esoteric scheduler, they can do it without making 
substantial changes to the rest of Xen. For example, our own work with 
Xen is focused on supporting things like military-strength 
non-interference security. To do that, we might want an esoteric scheduler.

-- 
What is the formal semantics of the one-line program
#include "/dev/tty"
----
    .~.                 _      _
    /V\                -o)    -o)
   /( )\               /\\    /\\
   ^^^^^              _\_v   _\_v

J. P. McDermott			Building 12
Code 5542			John.McDermott@NRL.Navy.mil
Naval Research Laboratory	Tel:   +1 202.404.8301
Washington, DC 20375, USA	Fax:   +1 202.404.7942	

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel