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

[Andrew Theurer <habanero@xxxxxxxxxx>]

On Tuesday 12 July 2005 14:08, Magenheimer, Dan (HP Labs Fort Collins) 
wrote:
> 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.

On dom0, will we then need a virtual cpu for each physical cpu in the 
box? I am assuming each idle cpu needs a virtual cpu from dom0 to 
"idle".  I usually use a uniprocessor kernel form dom0; wouldn't that 
create a problem?

Also, if dom0 idled during cpu slack time, is this a polling idle?  If 
so, that would not be good for HT.

IMO, I'm not sure we need any domain at all to idle.  Can't we have some 
sort of idle function in xen itself, which usually just sleeps the 
processor?

-Andrew

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