|
xen-devel
Re: [Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler re
|
To: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2 |
|
From: |
NISHIGUCHI Naoki <nisiguti@xxxxxxxxxxxxxx> |
|
Date: |
Thu, 15 Jan 2009 16:01:58 +0900 |
|
Cc: |
"Su, Disheng" <disheng.su@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Ian.Pratt@xxxxxxxxxxxxx" <Ian.Pratt@xxxxxxxxxxxxx>, "sakaia@xxxxxxxxxxxxxx" <sakaia@xxxxxxxxxxxxxx>, "aviv@xxxxxxxxxxxx" <aviv@xxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx> |
|
Delivery-date: |
Wed, 14 Jan 2009 23:02:49 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<4949BC2C.4060302@xxxxxxxxxxxxxx> <BB1F052FCDB1EA468BD99786C8B1ED2C01D260D043@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <496E99B9.3010906@xxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <496EBECC.8020405@xxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <496ED22A.3050708@xxxxxxxxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Thunderbird 2.0.0.19 (Windows/20081209) |
Tian, Kevin wrote:
From: NISHIGUCHI Naoki [mailto:nisiguti@xxxxxxxxxxxxxx]
Sent: Thursday, January 15, 2009 2:06 PM
If guest B does be always busy, then you may need to check the 30ms
credit allocation algorithm in credit scheduler. It looks
like some sequence
that guest A may be always granted as OVER priority due to
its earlier
overrun, until guestB also overruns a similar length. Then
in this punish
period, guest A has no chance to be boosted with all cycles
granted to
guest B instead. if it's intended for fairness p.o.v, it may
not suit for rt
usage.
Sorry, I didn't explain well.
I mean that softirq for scheduling (SCHEDULE_SOFTIRQ) might not occur
during hundreds of ms. I found similar issue when connecting vncviewer
to guest B. Guest B runs nothing. But I don't use Disheng's
configuration.
I assumed that this issue (Disheng said) is the same issue as mine.
Could you make sure of your statistics? Every schedule will have a
30ms timer set, regardless of whether current vcpu is repicked or a
new vcpu is chosen. s_timer_fn then issues SCHEDULE_SOFTIRQ
in 30ms interval.
When connecting vncviewer to guest B, s_timer_fn wasn't called in 30ms
interval.
My above writing is more about that time-sharing purpose for boost
is not enough toward rt purpose.
I agree that my approach is not enough for rt usage.
Regards,
Naoki
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home