Re: [Xen-devel] [Q] about Credit Scheduler Dom0 Scheduling policy.

[Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>]

Hi, Emmanuel,

Thank you for your comments,

Currently, I am testing on IA64.

CPU=1595MHz
itc=1595MHz


Thanks
Atsushi SAKAI

>On Mon, Oct 23, 2006 at 01:13:45PM +0900, Atsushi SAKAI wrote:
>> For including files
>>   For xentrace log, output size is huge 10lines/KB.
>>   I just included 100 line.
>
>These logs are interesting.
>
>According to the logs, some of our prior assumptions are shown
>to be incorrect.
>
>For one thing, it looks like SEDF does not do a good job at
>all at running either the I/O domU or dom0 quickly after they
>are made runnable. Often, it schedules both spinning domUs for
>a full time slice each before it gets to the I/O domU or dom0.
>
>The credit scheduler seems to schedule the I/O domU and dom0
>much more quickly when they become runnable. Basically it seems
>to work as advertised and preempt the CPU from the spinners.
>
>There is another weird thing going on: Every once in a while,
>both the I/O domU and dom0 are blocked. The sequence goes like
>this: I/O domU blocks, dom0 wakes and runs and blocks. A
>spinner runs a full time slice. Then, the I/O domU is woken up
>and runs. It takes a full time slice for this to happen though
>and time slices in the credit scheduler appears to be 60x that
>using SEDF (60 x !!!). The credit scheduler time slice is 30
>millisecs. The sedf scheduler appears to run the spinners for
>half a millisecond only even when it's only running both spinners
>and nothing else. Argueably, this is quite bad were the spinners
>to actually do anything useful with their cache.
>
>Because the time slices are that much shorter with SEDF, the
>dom0 actually often yields the CPU to the spinners before it
>can complete the work necessary to wake up the I/O domU.
>
>So my reading of the logs indicates to me that -- contrary to
>our initial theories -- the credit scheduler is much better in
>this workload than sedf at preempting CPU bound VCPUs to run
>I/O bound ones. The problem seems to be this odd behaviour
>where an I/O bound domU isn't woken up by dom0 until after an
>unrelated VCPU has completed a full time slice. Something
>seems broken there either with the tracing or with the I/O
>sleep/wake code because, according to the traces, dom0 at
>times runs and blocks without waking up the I/O domU.
>
>Are the chunks of traces you sent representative of the
>overall behaviour of the system?
>
>Also, your CPU is approx 1.48Ghz, right?
>







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