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

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

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [Q] about Credit Scheduler Dom0 Scheduling policy.
From: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>
Date: Wed, 18 Oct 2006 20:49:51 +0900
Delivery-date: Wed, 18 Oct 2006 04:51:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Emmanuel,

 Thank you for your previous comment.
I still waiting for second item comments.

Anyway, I want to ask you a opinion 
about the credit scheduler's vcpu scheduling policy.
(compare with the "sedf" scheduler)
The reason of this asking is
this matter should be related to I/O performance in Multi-VM.

My testing was done by following 3 DomUs. 
DomU1, DomU2(CPU intensive jobs are running)
DomU3(I/O intensive jobs are running)

By seeing xentrace, scheduling behavior seems differentiated by schedulers
especially Dom0(Driver Domain) vcpu scheduling policy
(I checked vcpu_wake and dispatched time difference.)

In SEDF-scheduler,
When Dom0 vcpu wakes, Dom0 vcpu gets pcpu resources immediately.
(in worst case the delay is within 1msec)
But in CREDIT-scheduler,
Sometime Dom0 vcpu have large latency.(sometimes 60msec)

I think this delayed reason is the behavior of credit scheduler.
In the credit scheduler,
When Dom0 vcpu wakes, Dom0 vcpu just adds in runq tail.
(this makes a problem.)

I think Dom0 vcpu wake up should be handled prioritize the UNDER runq.
Since it reflects response time especially I/O.


Of course,
CPU intensive job(in following document VCPU SPIN) domain is just one,
It has no problem, since runq has no vcpu.
http://www.xensource.com/files/summit_3/sched.pdf#page=4
In this case, if requesting context switch(SCHEDULE_SOFTIRQ) is occured,
it switches to VCPU I/O successfully.
But my example case(2 SPIN VCPU), a VCPU SPIN is in runq
(since 2 SPIN VCPU domain are exists).
In this case SCHEDULE_SOFTIRQ, just pushes another VCPU SPIN,
So VCPU I/O is not started.

Waiting for your opinion.

Thanks
Atsushi SAKAI

=============================================================
My Test Configuration is

#pcpu=1
#vcpu=1(Dom0, DomU1, DomU2, DomU3)

CPU intensive domain: DomU1 and DomU2
I/O intensive domain: DomU3
Privileged Domain   : Dom0 

CPU intensive domain runs cpu-loop
like follows,
main(){int a;while(1){a++;};}

I/O intensive domain runs fsdisk
(which is included in unixbench 4.1.0)

Privileged Domain runs
xenmon.py or 
xentrace in standard configuration(uses tools/xentrace/formats)
The xentrace output is included in this mail.
(I picked up the problem from xentrace outputs.)
=============================================================

Attachment: xentrace-credit-sedf.log
Description: Binary data

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