[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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?

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.