|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler re
To: |
'NISHIGUCHI Naoki' <nisiguti@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx> |
Subject: |
RE: [Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2 |
From: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx> |
Date: |
Thu, 15 Jan 2009 14:41:26 +0800 |
Accept-language: |
en-US |
Acceptlanguage: |
en-US |
Cc: |
"Su, Disheng" <disheng.su@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "sakaia@xxxxxxxxxxxxxx" <sakaia@xxxxxxxxxxxxxx>, "Ian.Pratt@xxxxxxxxxxxxx" <Ian.Pratt@xxxxxxxxxxxxx>, "aviv@xxxxxxxxxxxx" <aviv@xxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx> |
Delivery-date: |
Wed, 14 Jan 2009 22:42:30 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<496ED22A.3050708@xxxxxxxxxxxxxx> |
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> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
Acl212CkfPCaEp8nTMmH/cwMd6P7wgAAQyoQ |
Thread-topic: |
[Xen-devel] RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2 |
>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.
My above writing is more about that time-sharing purpose for boost
is not enough toward rt purpose.
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|