| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Some thoughts about the soft real time scheduler for Xen
> Frist, a (partial) recap of what Ian said before:
>
> ======================================
> We need a compile (or run time) option to completely replace the
> current BVT scheduler with a soft real time scheduler that allows
> domains to be given guarantees of the form "x microseconds every
> y microseconds" (having a constraint that y must be a power of 2
> or suchlike would be fine)
>
> If there's CPU time left over after meeting the guarantees of all
> the runnable domains, it should be shared out in a proportional
> manner between domains that have an 'eligible for best-effort
> extra time' flag set.
> ======================================
>
> Some questions:
>
> 1. According to the "2003 Xenoserver Computing Infrastructure", in a
> commercial production environment clients are supposed to "buy" the
> computing time from Xenoserver, customers may not be happy with only soft
> real time QoS?
In the context of XenoServers, the notion is that you pay for e.g.
S ms every P ms, where the total demand from all domains clearly needs
to be less than e.g. 100% assuming EDF.
However: if there is K% of the CPU remaining, we would like to be able
to choose whether to dole this out to some subset of all domains, or
to simply 'waste' it. The subset sharing the 'slack time' may or may
not include any paying customers (e.g. it might involve running
maintenance tasks for the XenoServer).
In the non-XenoServer case (e.g. more traditional web hosting world),
the use of a work conserving scheduler seems to make lots of sense.
A scheduler which allows both these extremes (hard QoS & best effort)
would hence we a very nice thing.
> 2. I am working on a (simple) absolute share scheduler function in Xen,
> which should provide the bottom line for what a customer buy from
> Xenoserver. But I guess a hybrid scheduler combining these two is desirable
> in the future?
Yup!
> 3. For a Xenolinux (domain) to specify meaningful QoS requests, it has
> to gather information from application processes and inform them to Xen. In
> the literature there are serveral approaches such as directly modifying the
> kernel scheduler to be fully preemptible (preserving original interface),
> implementing new extension as module, using " dual kernels" by providing a
> thin layer between Linux kernel and interrupt control hardward (real time
> tasks interact with another [real time] kernel interface). Xen shows
> properties like some of these in the way that it sits below standard Linux
> like "dual kernel", and, that application processes run unmodified. Besides
> Xen's scheduler, the schduler in Xenolinux needs to be changed. Any idea how
> this should be implemented in Xenolinux? Which approach is more appropriate?
So in principle a XenoLinux (or other guest) scheduler could certainly
export some 'real-time' scheduling notions to its hosted processes.
However this is not at all a requirement for us; in particular our
experience with Nemesis showed that the sorts of QoS requirements
people actually have in general are rather coarse... e.g. some notion
of "an aggregate machine which is about 15% as powerful as a the
real one". We'd like to support higher-level QoS specs (e.g. "a
machine which is capable of scoring 225 on SPEC WEb99") and have a
plan for this. But none of this involves tweaking any of the
scheduling in XenoLinux or other guests.
cheers,
S.
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home