WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Steven Hand" <Steven.Hand@xxxxxxxxxxxx>, "Devel Xen" <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Some thoughts about the soft real time scheduler for Xen
From: "Yan-Ching CHU" <cs0u210a@xxxxxxxxxxxxxxx>
Date: Wed, 18 Feb 2004 20:16:30 -0000
Cc: <cs0u210a@xxxxxxxxxxxxxxx>
Delivery-date: Wed, 18 Feb 2004 20:16:46 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
References: <E1AtWkx-0002xI-00@xxxxxxxxxxxxxxxxxxxx>
Thanks Steven that really clarified things a lot.


Yan-Ching CHU



----- Original Message ----- 
From: "Steven Hand" <Steven.Hand@xxxxxxxxxxxx>
To: "Yan-Ching CHU" <cs0u210a@xxxxxxxxxxxxxxx>
Cc: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>; <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 18, 2004 6:49 PM
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.
>
> >     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
>