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

[NISHIGUCHI Naoki <nisiguti@xxxxxxxxxxxxxx>]

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