[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: IDLE domain is scheduled more than dom0
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |