From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emmanuel Ackaouy Subject: Re: [Q] about Credit Scheduler Dom0 Scheduling policy. Date: Wed, 25 Oct 2006 11:29:49 +0100 Message-ID: <20061025102948.GA32281@cockermouth.uk.xensource.com> References: <200610181150.k9IBoP8W031962@fjmscan502.ms.jp.fujitsu.com> <20061018131115.GA5327@cockermouth.uk.xensource.com> <20061018132410.GA5372@cockermouth.uk.xensource.com> <200610230414.k9N4EKGJ011580@fjmscan501.ms.jp.fujitsu.com> <20061023143210.GA26848@cockermouth.uk.xensource.com> <200610240647.k9O6lYQR004608@fjmscan503.ms.jp.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Return-path: Content-Disposition: inline In-Reply-To: <200610240647.k9O6lYQR004608@fjmscan503.ms.jp.fujitsu.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: Atsushi SAKAI Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thanks for sending me the full logs! I took a look and I do indeed see some cycles during which dom0 and the I/O generating domU don't preempt the spinners. I believe this is because those domains don't always consume enough CPU to appear in the accounting paths. I have coded up a fix which should make things better for I/O intensive domains that use few CPU resources. I am including the patch here. It applies to tip of untable. Can you try out this patch and let me know how it works? Thanks, Emmanuel. --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sched-wake-boost.patch" diff -r 0c7923eb6b98 xen/common/sched_credit.c --- a/xen/common/sched_credit.c Wed Oct 25 10:27:03 2006 +0100 +++ b/xen/common/sched_credit.c Wed Oct 25 11:11:22 2006 +0100 @@ -46,6 +46,7 @@ /* * Priorities */ +#define CSCHED_PRI_TS_BOOST 0 /* time-share waking up */ #define CSCHED_PRI_TS_UNDER -1 /* time-share w/ credits */ #define CSCHED_PRI_TS_OVER -2 /* time-share w/o credits */ #define CSCHED_PRI_IDLE -64 /* idle */ @@ -410,6 +411,14 @@ csched_vcpu_acct(struct csched_vcpu *svc spin_unlock_irqrestore(&csched_priv.lock, flags); } + + /* + * If this VCPU's priority was boosted when it last awoke, reset it. + * If the VCPU is found here, then it's consuming a non-negligeable + * amount of CPU resources and should no longer be boosted. + */ + if ( svc->pri == CSCHED_PRI_TS_BOOST ) + svc->pri = CSCHED_PRI_TS_UNDER; } static inline void @@ -566,6 +575,25 @@ csched_vcpu_wake(struct vcpu *vc) else CSCHED_STAT_CRANK(vcpu_wake_not_runnable); + /* + * We temporarly boost the priority of awaking VCPUs! + * + * If this VCPU consumes a non negligeable amount of CPU, it + * will eventually find itself in the credit accounting code + * path where its priority will be reset to normal. + * + * If on the other hand the VCPU consumes little CPU and is + * blocking and awoken a lot (doing I/O for example), its + * priority will remain boosted, optimizing it's wake-to-run + * latencies. + * + * This allows wake-to-run latency sensitive VCPUs to preempt + * more CPU resource intensive VCPUs without impacting overall + * system fairness. + */ + if ( svc->pri == CSCHED_PRI_TS_UNDER ) + svc->pri = CSCHED_PRI_TS_BOOST; + /* Put the VCPU on the runq and tickle CPUs */ __runq_insert(cpu, svc); __runq_tickle(cpu, svc); @@ -659,7 +687,7 @@ csched_runq_sort(unsigned int cpu) next = elem->next; svc_elem = __runq_elem(elem); - if ( svc_elem->pri == CSCHED_PRI_TS_UNDER ) + if ( svc_elem->pri >= CSCHED_PRI_TS_UNDER ) { /* does elem need to move up the runq? */ if ( elem->prev != last_under ) --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --ew6BAiZeqk4r7MaW--