RE: [Xen-devel] Scheduling of I/O domains

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

the scheduler should also be entered if an event (in this case a
virtualized interrupt) is delivered to a domain by Xen (and not just on
a timer interrupt). In particular the event delivery mechanisms should
check if the receiving domain is blocked, if so, wake it up and enter
the scheduler.

It is debatable if an already running/runable domain should be given
special treatment if a virtualized HW interrupt or an event in general
is delivered to it. because the scheduler should also provide an upper
bound or some notion of fairness on the CPU time received by domains if
they receive lots of events.

In general we are aware of some scheduler 'issues' with more IO bound
domains in the presence of cpu bound domains (and in this sense IO
domains and IO bound domains are pretty similar).

I have a look tomorrow once I my workstation is back up in a usable
state, and as gregor pointed out, he is also looking into this.
Hopefully we can resolve this issue reasonably quick.

rolf

> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Rob Gardner
> Sent: 21 July 2004 23:25
> To: G. Milos
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Scheduling of I/O domains
> 
> G. Milos wrote:
> >
> > To target the unfairness I am developing a modification of BVT (I
called
> > it Fair Borrowed Virtual Time [FBVT]). You can enable it by
supplying
> > "sched=fbvt" command to Xen at the startup. The scheduler is under
> > development and it needs some tweaking to get the best performance
(that
> > is what I am working on at the moment). It would be very helpful if
you
> > could email me with the results of your tests for FBVT.
> 
> 
> I tried booting xen with "sched=fbvt" in the command line in
grub.conf.
> It didn't change the results at all. And why would it? We are not
> dealing with an "I/O bound domain" here, but rather with an "I/O
> domain", two very different things.
> 
> It seems to me that this problem doesn't have anything to do with the
> choice of scheduling policy or parameters; It is about when the
> scheduler is called. It appears as though the xen cpu scheduler
> currently only runs when the hardware timer ticks. It does not run
when
> an external interrupt happens. So there is a large latency introduced
to
> I/O interrupts, and this limits I/O performance. Changing the
scheduler
> algorithm won't help this.
> 
> The only way to avoid this is to immediately dispatch the I/O domain
> responsible for a given I/O interrupt as soon as that interrupt
occurs.
> This means giving I/O domains with pending interrupts scheduling
> priority over any "regular" domains. Just as in a "normal" operating
> system, interrupt service routines must complete before any user
> processes are executed. Otherwise, latencies are introduced that kill
> I/O performance.
> 
> Rob Gardner
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel