[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 >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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |