WARNING - OLD ARCHIVES

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/
Xen

xen-devel

[Top] [All Lists]

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: 2005年7月13日 11:23:44 +0100
Delivery-date: 2005年7月13日 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. 
Ian 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<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 <=
Previous by Date: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs. , Gerd Knorr
Next by Date: Re: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs. , Keir Fraser
Previous by Thread: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs. , Gerd Knorr
Next by Thread: RE: [Xen-devel] Re: [Xen-changelog] Fix NX/XD enable on secondary CPUs. , Petersson, Mats
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /