From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RE: The caculation of the credit in credit_scheduler Date: Wed, 10 Nov 2010 07:03:49 +0100 Message-ID: <4CDA35C5.7060806@ts.fujitsu.com> References: <789F9655DD1B8F43B48D77C5D30659732FD0A5C9@shsmsx501.ccr.corp.intel.com> <4CD95A22.2090902@eu.citrix.com> <789F9655DD1B8F43B48D77C5D30659732FD7DF70@shsmsx501.ccr.corp.intel.com> <4CDA31A8.4050308@ts.fujitsu.com> <789F9655DD1B8F43B48D77C5D30659732FD7E0EC@shsmsx501.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: <789F9655DD1B8F43B48D77C5D30659732FD7E0EC@shsmsx501.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: "Jiang, Yunhong" Cc: George Dunlap , "xen-devel@lists.xensource.com" , "Dong, Eddie" , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org On 11/10/10 06:55, Jiang, Yunhong wrote: > > >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Juergen Gross >> Sent: Wednesday, November 10, 2010 1:46 PM >> To: Jiang, Yunhong >> Cc: George Dunlap; xen-devel@lists.xensource.com; Dong, Eddie; Zhang, Xiantao >> Subject: Re: [Xen-devel] RE: The caculation of the credit in credit_scheduler >> >> On 11/10/10 03:39, Jiang, Yunhong wrote: >>> >>> >>>> -----Original Message----- >>>> From: George Dunlap [mailto:George.Dunlap@eu.citrix.com] >>>> Sent: Tuesday, November 09, 2010 10:27 PM >>>> To: Jiang, Yunhong >>>> Cc: xen-devel@lists.xensource.com; Dong, Eddie; Zhang, Xiantao >>>> Subject: Re: The caculation of the credit in credit_scheduler >>>> >>>> On 05/11/10 07:06, Jiang, Yunhong wrote: >>>>> The reason is how the credit is caculated. Although the 3 HVM domains is >> pinned >>>> to 2 PCPU and share the 2 CPUs, they will all get 2* 300 credit when credit >> account. >>>> That means the I/O intensive HVM domain will never be under credit, thus it will >>>> preempt the CPU intensive whenever it is boost (i.e. after I/O access to QEMU), >> and >>>> it is set to be TS_UNDER only at the tick time, and then, boost again. >>>> >>>> I suspect that the real reason you're having trouble is that pinning and >>>> the credit mechanism don't work very well together. Instead of pinning, >>>> have you tried using the cpupools interface to make a 2-cpu pool to put >>>> the VMs into? That should allow the credit to be divided appropriately. >>> >>> I have a quick look in the code, and seems the cpu pool should not help on such >> situation. The CPU poll only cares about the CPUs a domain can be scheduled, but >> not about the credit caculation. >> >> With cpupools you avoid the pinning. This will result in better credit >> calculation results. > > My system is doing testing, so I can't do the experiment now, but I'm not sure if the cpupool will help the credit caculation. > >> From the code in csched_acct() at "common/sched_credit.c", the credit_fair is caculated as followed, and the creadt_fair's original value is caculated by sum all pcpu's credit, without considering the cpu poll. > > credit_fair = ( ( credit_total > * sdom->weight > * sdom->active_vcpu_count ) > + (weight_total - 1) > ) / weight_total; > > Or did I missed anything? The scheduler sees only the pcpus and domains in the pool, as it is cpupool specific. BTW: the credit scheduler's problem with cpu pinning was the main reason for introducing cpupools. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html