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/
Home Products Support Community News


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

To: Rob Gardner <rob.gardner@xxxxxx>
Subject: Re: [Xen-devel] Scheduling of I/O domains
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 22 Jul 2004 01:53:26 +0100
Cc: "G. Milos" <gm281@xxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 22 Jul 2004 01:56:41 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 21 Jul 2004 16:25:26 MDT." <40FEED56.7040109@xxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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.

When an event is queued for a domain we call a generic wakeup
function. A good deal more of that function ought to be
scheduler-specific, and should do something smarter than our current
default (which is to force a reschedule only if the CPU is idling).
However, fixing this shouldn't be that hard -- we should have saner
scheduling in the next few weeks.

 -- Keir

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.
Xen-devel mailing list