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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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.

That's not quite true. The idle domain is treated specially, and
typically runs under the pagetables of the previously running domain,
often avoiding pagetable base switches for domains that block briefly.
The is a win on x86 systems as it avoids a TLB flush. It's less of an
issue for Opteron due to the TLB flush filter.

It's a bit sad that saving the register context on IA64 takes so long
that we have to considering tricks like this. Rather than getting rid of
the idle domain it may be better to add the concept of lazy switching of
register state, as we do for mm state. 

Ian 

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