From mboxrd@z Thu Jan  1 00:00:00 1970
From: Emmanuel Ackaouy <ack@xensource.com>
Subject: Re: [Q] about Credit Scheduler Dom0 Scheduling policy.
Date: Wed, 25 Oct 2006 15:03:37 +0100
Message-ID: <20061025140337.GA819@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>
	<20061025102948.GA32281@cockermouth.uk.xensource.com>
	<200610251303.k9PD3CpQ017617@fjmscan501.ms.jp.fujitsu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <200610251303.k9PD3CpQ017617@fjmscan501.ms.jp.fujitsu.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Atsushi SAKAI <sakaia@jp.fujitsu.com>
Cc: xen-devel@lists.xensource.com
List-Id: xen-devel@lists.xenproject.org

On Wed, Oct 25, 2006 at 10:02:35PM +0900, Atsushi SAKAI wrote:
> Hi, Emmanuel
> 
>  Thank you for your patches.
> I tested on my environment
> 
> 1)Credit w/ Boost
> 2)Credit(previous)
> 3)SEDF(previous)
> 
>   1   2    3
>  44  16   33
> 133  66  133
> 533 266  266
> (Kbps)

Wow. This is quite an improvement!

Out of curiosity, what are the numbers like when running this
benchmark with no spinning VCPUs competing?

> With this patches, the CREDIT scheduler changed for I/O aware.
> (At vcpu_wake, the priority changes from UNDER to BOOST,
> At vcpu_acct, the priority changes from BOOST to UNDER.) 
> 
> It seems reasonable fixes!
> But I am afraid many I/O intensive GuestOSes are running.
> (I hope this prospect is needless fear.)

I've been careful to prevent BOOSTed VCPUs from taking over the
system or otherwise impacting fairness:

- Only VCPUs with positive credits can be boosted.
- While boosted, a VCPU is charged for any substential CPU
  resources consumed.
- VCPUs can run uninterrupted with a boosted priority for no
  more than 10ms (1/3-rd of a full time slice).

Only VCPUs which consume a negligeable amount of CPU resources
should get real benefit from boosting. When multiple VCPUs are
boosted, they will round robin or be queued FIFO. The idea is
for a boosted VCPU to preempt spinners but not other boosted
I/O intensive guests. A VCPU cannot use the boosting mechanism
to consume more CPU than its allocated fair share.