[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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 
>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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.