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


[Xen-devel] Why have an idle domain? (Was: IDLE domain is scheduled more

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Why have an idle domain? (Was: IDLE domain is scheduled more than dom0)
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 12 Jul 2005 12:08:06 -0700
Delivery-date: Tue, 12 Jul 2005 19:07:13 +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: AcWHFQkIDf2z2mKaTNCYhuB+gLglmQ==
Thread-topic: Why have an idle domain? (Was: IDLE domain is scheduled more than dom0)
I wanted to start a new thread on this so it doesn't get
buried in the old one.

Why is there an idle domain at all?  Certainly OS schedulers
need one and, yes, I understand that it makes it a tiny bit
easier to not have any special cases in the scheduler, but
Xen isn't a (normal) OS and there is a very good reason NOT to
have an idle domain: Namely that context switching is not free.
It is very expensive on some machines; it may be cheap on an x86
but it is still not free.

The issue is what domain is running when a device interrupt arrives.
If it is the idle domain, then a domain switch is required before
it can be "delivered" to domain0.  This adds unnecessary latency
to interrupts... although small it CAN add up.  (The 1% measured
by Kevin in the previous thread is still unacceptable as far as
I'm concerned.)

What I propose is that domain0 become the idle domain.  Special
casing code would be added to the schedulers so that domain0
is always runnable and thus will absorb any "idle" cycles.

What if domain0 is not the target for the device interrupt?
Although some Xen configurations will have multiple driver
domains, this is probably an exception rather than the rule.
And "domain0 as the idle domain" will provide no worse interrupt
latency than "idle as the idle domain" for interrupts that
must be delivered to the non-domain0 driver domains.

So is there any good reason to have an idle domain other than
because that's the way OS schedulers have always done it?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>