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
|
Home