WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: IDLE domain is scheduled more than dom0

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: IDLE domain is scheduled more than dom0
From: Stephan Diestelhorst <sd386@xxxxxxxxxxxx>
Date: Tue, 12 Jul 2005 13:24:30 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Jul 2005 12:25:19 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8074783A6@pdsmsx403>
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>
References: <571ACEFD467F7749BC50E0A98C17CDD8074783A6@pdsmsx403>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.6.2
Hi Kevin,
  that's good news! 
> 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. ;-)

Don't worry, similar things happened to me... With boot-times up to 10 
minutes, because I didn't realize that time-outs were relative, not absolute. 
Resulted in an nice exponential curve :-)

Thanks for your testing!

Stephan
>
> >-----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
> >>Diestelhorst
> >>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 timer, 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 still 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
> >
> >much
> >
> >>difference (even to BVT) and the idle-task always has 4-5 times as much
> >
> >CPU
> >
> >>time as dom0. In my setup this is due to mounting of NFS devices, which
> >
> >takes
> >
> >>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,
> >Kevin
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@xxxxxxxxxxxxxxxxxxx
> >http://lists.xensource.com/xen-devel

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