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: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Hollis Blanchard" <hollisb@xxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 14 Jul 2005 10:45:37 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Jul 2005 02:44:30 +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/xXgGKT1SJ2nzadQDUZwAAw4nQABW/obAAAiXMYA==
Thread-topic: [Xen-devel] RE: [Patch] Fix IDLE issue with sedf scheduler on IA64
>From: Ian Pratt [mailto:m+Ian.Pratt@xxxxxxxxxxxx]
>Sent: Thursday, July 14, 2005 9:24 AM
>If you really want to do something like this, it would be much better
>just to detect a switch to the idle domain (on whatever CPU dom0
>to be running on) and load the register and mm state for dom0 and make
>it appear to be the last domain that ran.  The lazy switching logic
>then take care of things.

I'm still doubt the really gain of "not switch to idle", which may bring
dom0 less period on real job compared to other domains. Saying current
model, dom0 is requesting to block in its own idle loop. In this way,
dom0's idle loop doesn't occupy any real slice, and the whole period
allocated to dom0 is all spent on meaningful job. Then let's not switch
to idle domain with some trick in context_switch. What's happen? If dom0
is in idle loop and request to block, its next period/slice is set as
20ms and scheduler decides to switch to IDLE with next expire for
scheduler is 2ms. Then in context_switch, idle domain is instead
replaced by Dom0 which may simply does idle loop too. When next schedule
happens, 2ms is minus from Dom0's slice however this 2ms is likely to be
spent on completely useless loop. Finally in this period, Dom0 only gets
18ms to do real job, and I think this will also affect the throughput of
Dom0. Just take a special case as example here... :-) So we need to
balance based on future experimental data.


Xen-devel mailing list