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] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Hollis Blanchard" <hollisb@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 14 Jul 2005 10:01:17 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Jul 2005 02:00:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWHt6n1Iv/xXgGKT1SJ2nzadQDUZwAAw4nQABVBOYA=
Thread-topic: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
>From: Magenheimer, Dan (HP Labs Fort Collins)
>Sent: Wednesday, July 13, 2005 11:05 PM
>Neat, but doesn't this only solve half the problem?  Idle is now
>an "impostor" for the last runnable domain.  Generally the machine
>goes idle because all domains are waiting for a device interrupt.
>Since (in general) all device interrupts go through domain0,
>a context switch is still necessary from idle=last_runnable_domain
>to domain0 to process the device interrupt, then back to domU to
>process the virtual interrupt.
>In a I/O bound system, interrupt latency still seems to be
>twice what it could be.
>A related idea though for the scheduler experts to think about:
>Is it possible for idle to be an "alias" for domain0?

If Dom0 is always doing meaningful job, that's possibly wanted. However
I'm not sure whether this approach has better performance on the other
side... Say dom0 is requesting to block explicitly (in its idle loop due
to bunch of I/O sessions), to always schedule dom0 (eliminating IDLE)
actually lets do_block returned immediately to idle loop in dom0, which
will issue another do_block to Xen, and then such heavily context switch
will continue until a new schedule or expected events happens.

Then the net effect is actually to move idle concept from Xen into Dom0,
when hardware really wants to sleep. However this is much worse than
idle loop in Xen (current IDLE domain), because more power are consumed
unexpectedly due to too many context switches. More, scheduler will be
triggered with more latency then, because context switch is more boring
with dom0 compared with IDLE domain. Less optimization can be done.


Xen-devel mailing list