[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.