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] [Q] about Credit Scheduler Dom0 Scheduling policy.

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