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: IDLE domain is scheduled more than dom0

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Stephan Diestelhorst" <sd386@xxxxxxxxx>
Subject: RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 12 Jul 2005 19:38:11 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Jul 2005 11:37:00 +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: AcWGTwA80Xot/ZLoS0yVOQmV5LfzTQAQzhBQABBENlA=
Thread-topic: [Xen-devel] Re: IDLE domain is scheduled more than dom0
Hi, Stephan,
        I finally track down the problem to be caused by some bug in XEN/IA64 
itself. Due to some code not suitable running with IDLE domain, sometimes the 
delta for next timer tick was changed to a very large value when current 
context is IDLE. Then IDLE ran a relative long period without timer interrupt 
happening. Finally evaluated cpu_time for IDLE became large due to above bug, 
though only be scheduled several times. Similar bugs were hidden previously on 
bvt scheduler, due to IDLE never be scheduled after DomN was up. 

        With a simple workaround, now IDLE only occupied about 1% time, with 
Dom0 to grasp 99%. Then I'll push out a patch to fix that issue soon. Sorry for 
blaming your scheduler and it actually looks very nice based on data collected 
by you. ;-)

Thanks a lot for help,

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Tian, Kevin
>Sent: Tuesday, July 12, 2005 12:10 PM
>To: Stephan Diestelhorst
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] Re: IDLE domain is scheduled more than dom0
>>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Stephan
>>Sent: Monday, July 11, 2005 11:34 PM
>>Kevin Tian's measurements (on IA64 hardware):
>>SEDF: dom0 (15/20, xoff)
>>Dom0                  0x5420288a1b = 361316780571 ~ 361.3 sec
>>IDLE                  0x93def9294f = 635101063503 ~ 635.1 sec
>>-> total boot time: 996.4 sec ?!
>>   ratio: 0.57
>This data was collected until login prompt. Currently still some issue with 
>so that value may not be exact accurate. However I did observe that total boot
>time is about 5 times slower than BVT or the 3rd case, with IDE probe
>especially slow. I haven't figure out exact reason yet, and just wonder whether
>some different behavior on IA64 may exaggerate that issue...
>>SEDF: dom0(15/20, xon)
>>Dom0                  0x1040A91728 =  69804300072 ~  69.8 sec
>>IDLE                  0x19CE88F3E7 = 110839264231 ~ 110.8 sec
>>-> total boot time: 180.6 sec
>>   ratio: 0.63
>Sorry for this inaccurate data, upon which I stopped test at IDE probe due to
>slow progress. Rough sense is similar to first case, and anyhow the ratio is 
>not acceptable.
>>SEDF: dom0(20/20, xoff)
>>Dom0                  0x2D61AF8D5D = 194912423261 ~ 194.9 sec
>>IDLE                    0x48FD92BF =   1224577727 ~   1.2 sec
>>-> total boot time: 196.1 sec
>>   ratio: 162.42
>This one was also collected for whole boot process until login prompt.
>>As you see, for me the fiddling with the parameters of sedf doesn't make
>>difference (even to BVT) and the idle-task always has 4-5 times as much
>>time as dom0. In my setup this is due to mounting of NFS devices, which
>>quite a while, where dom0 is blocked most of the times. So our times might
>>not be comparable.
>So yes, they're not comparable. In your environment, too many I/O of Dom0
>gives up time slice actively, which may shade effect when IDLE is scheduled
>more unexpectedly. However in my test environment, Dom0 never blocks
>actively even when doing I/O operation (Current status), which can be
>considered as a special case to make that corner case more obvious...
>Thanks a lot,
>Xen-devel mailing list

Xen-devel mailing list