From mboxrd@z Thu Jan 1 00:00:00 1970 From: NISHIGUCHI Naoki Subject: Re: RE: [RFC][PATCH 0/4] Modification of credit scheduler rev2 Date: Thu, 15 Jan 2009 16:01:58 +0900 Message-ID: <496EDF66.1000402@jp.fujitsu.com> References: <4949BC2C.4060302@jp.fujitsu.com> <496E99B9.3010906@jp.fujitsu.com> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB4@pdsmsx502.ccr.corp.intel.com> <496EBECC.8020405@jp.fujitsu.com> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB5@pdsmsx502.ccr.corp.intel.com> <496ED22A.3050708@jp.fujitsu.com> <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB6@pdsmsx502.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0A882F4D99BBF6449D58E61AAFD7EDD603BB4AB6@pdsmsx502.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" , "xen-devel@lists.xensource.com" Cc: "Su, Disheng" , George Dunlap , "Ian.Pratt@eu.citrix.com" , "sakaia@jp.fujitsu.com" , "aviv@neocleus.com" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org 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