RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Magenheimer, Dan (HP Labs Fort Collins)
>[mailto:dan.magenheimer@xxxxxx]
>Sent: Wednesday, July 13, 2005 11:05 PM
>
>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?
>
>Dan

If Dom0 is always doing meaningful job, that's possibly wanted. However
I'm not sure whether this approach has better performance on the other
side... Say dom0 is requesting to block explicitly (in its idle loop due
to bunch of I/O sessions), to always schedule dom0 (eliminating IDLE)
actually lets do_block returned immediately to idle loop in dom0, which
will issue another do_block to Xen, and then such heavily context switch
will continue until a new schedule or expected events happens.

Then the net effect is actually to move idle concept from Xen into Dom0,
when hardware really wants to sleep. However this is much worse than
idle loop in Xen (current IDLE domain), because more power are consumed
unexpectedly due to too many context switches. More, scheduler will be
triggered with more latency then, because context switch is more boring
with dom0 compared with IDLE domain. Less optimization can be done.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel