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] Why have an idle domain? (Was: IDLE domain is scheduledm

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Why have an idle domain? (Was: IDLE domain is scheduledmore than dom0)
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 13 Jul 2005 11:23:44 +0100
Delivery-date: Wed, 13 Jul 2005 10:22:26 +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+gLglmQAdN7gA
Thread-topic: [Xen-devel] Why have an idle domain? (Was: IDLE domain is scheduledmore than dom0)
> 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. 


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Xen-devel] Why have an idle domain? (Was: IDLE domain is scheduledmore than dom0), Ian Pratt <=