RE: [Xen-devel] Some thoughts about the soft real time scheduler for Xen

["Neugebauer, Rolf" <rolf.neugebauer@xxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Steven Hand
> Sent: 18 February 2004 18:49
> To: Yan-Ching CHU
> Cc: Ian Pratt; xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: 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.

I think, this is the easy part, i.e., writing a scheduler which provides
some absolute guarantees (s ms every p ms) with some proportional share
of slack CPU time. 

I think, the tricky bit is to deal with wakeup latencies. Pure EDF and
other classic RT scheduling algorithms do not have the concept of
unblocking tasks and any addition providing special treatments to reduce
wakeup latencies screw the guarantees...I haven't come across a nice SRT
scheduler with these properties.

The current BVT scheduler has some story about reducing wake-up
latencies (in a somewhat similar way to latency parameter the Nemesis
atropos scheduler) and is work conserving. One can also guarantee
absolute shares of the CPU to domains by doing admission control on the
weights assigned to all domains (nothing new there). These guarantees
would be of x % over some time interval (which I believe can be proven
to have an upper bound depending on number of tasks and/or some fixed
parameters like context switch allowance etc modulo the effect of short
term fairness violation for reduced wakeup latencies...) rather than
specifying different periods per domain. However, I think BVT is a bit
tricky to configure with too many non-intuitive parameters!

The way to go is probably to have a choice of scheduling algorithms and
an easy way to 'plug in' new ones and choose between them.

And then there is the SMP can of worms...

Rolf

> >     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