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


[Xen-ia64-devel] RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf sc

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 13 Jul 2005 08:08:54 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 13 Jul 2005 15:07:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWHkNam4njROoPTSRq2Lw7NMoU4SwAE6cuAAAJhJYAAA5hiwA==
Thread-topic: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
(ia64 only since this is an archdep solution)

> >Is there a better way (for ia64)?  I kind of like the solution
> >Keir and Ian imply... is it possible in context_switch to simply
> >"refuse" to switch to the idle domain?   E.g. if the idle domain
> >is the target of the switch, instead switch to domain0 (and
> >make it runnable)?
> >
> This seems not easy to be simply done in context_switch without common
> change. Preventing switch to IDLE is easy, and a simple check in
> context_switch can achieve. However the really bad thing is about
> housekeep info within scheduler. Eg. domain0 may have been placed on
> waitq, with begin of next period still far away. Stealing 
> slice of IDLE
> to Dom0 without notifying scheduler, may mess the future 
> decision since
> next schedule will happen on Dom0's context and base on 
> dom0's statistic
> info...

I think domain0 only goes in the waitq at one point -- when
it calls pal_halt_light to idle its virtual machine.  This
case could be easily changed (there is already some code there)
to ensure domain0 is always runnable.


Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>