Re: RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2

[NISHIGUCHI Naoki <nisiguti@jp.fujitsu.com>]

Tian, Kevin wrote:
>> From: NISHIGUCHI Naoki [mailto:nisiguti@jp.fujitsu.com] 
>> 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