This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Capping i/o ops

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Capping i/o ops
From: Pim van Riezen <pi+lists@xxxxxxxxxxxx>
Date: Mon, 17 Sep 2007 21:20:24 +0200
Delivery-date: Mon, 17 Sep 2007 12:20:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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?

Pim van Riezen

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>