From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shaun R." Subject: Re: Capping i/o ops Date: Wed, 19 Sep 2007 00:59:40 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I would like to also see this, when we used UML a patch created by Chris at linode allowed for a guest to be throttled. The system worked on tokens, where each vps had a bucket full of tokens and each IO operation used 1 token and the bucked was refilled with a specified amount of tokens per second. If the bucket ran dry the user was throttled and had to wait until the bucket had more tokens added to it. http://theshore.net/~caker/patches/token-limiter-v5.patch here's the patch might give you some type of idea of what to do... ~Shaun "Pim van Riezen" wrote in message news:DAC7D946-A93F-47AC-B033-699933363075@panelsix.com... > Hi All, > > I've been trying to get a bit of a grip on disk i/o for our Xen set- up. > We're dealing with server workloads that can, at unexpected times, become > seriously io-bound, up to the point that a single guest can cannibalize > the available throughput of the fibrechannel array. Since we're dealing > with a shared medium and multiple Xen hosts, I'm looking for a way in to > put an upper cap on the number of i/o operations individual guests can > perform. > > Although this is not entirely scientific, it would allow an informed > administrator to limit the amount of operations guest A on host X can > perform to e.g., 50% of an observed maximum, so that guest B on host Y is > still guaranteed access at a minimum performance level. The case could > also be made for giving quality of service assurances on the single host > level, but the multiple host scenario is the more interesting viewpoint: > It precludes solutions that entail automatic optimizations - there are no > trivial automatic solutions to be had in this scenario. > > I'm not afraid to get my hands dirty and come up with a proof of concept > or even completer patch, but before I dive in, would this approach stand > a decent chance at making sense? The current approach seems to be "throw > the requests at the block layer and let the kernel, the hardware, or God > sort it out". Has any previous thought been given to this problem area > that I can/should read up about? > > Cheers, > Pim van Riezen