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] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64

To: "Hollis Blanchard" <hollisb@xxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: 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:05:24 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 13 Jul 2005 15:04:06 +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: AcWHt6n1Iv/xXgGKT1SJ2nzadQDUZwAAw4nQ
Thread-topic: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
> >> Magenheimer, Dan (HP Labs Fort Collins) wrote:
> >>
> >> 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...
> See how x86 does this in context_switch() (arch/x86/domain.c). In 
> particular, __context_switch is avoided for the idle domain, so the 
> context restored is some register pops in 
> ret_from_intr/restore_all_xen 
> (arch/x86/x86_32/entry.S).

Neat, but doesn't this only solve half the problem?  Idle is now
an "impostor" for the last runnable domain.  Generally the machine
goes idle because all domains are waiting for a device interrupt.
Since (in general) all device interrupts go through domain0,
a context switch is still necessary from idle=last_runnable_domain
to domain0 to process the device interrupt, then back to domU to
process the virtual interrupt.

In a I/O bound system, interrupt latency still seems to be
twice what it could be.

A related idea though for the scheduler experts to think about:
Is it possible for idle to be an "alias" for domain0? 


Xen-devel mailing list