From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nivedita Singhvi <niv@us.ibm.com>
Subject: Re: poor domU VBD performance.
Date: Thu, 31 Mar 2005 08:27:30 -0800
Message-ID: <424C24F2.1040002@us.ibm.com>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3930@liverpoolst.ad.cl.cam.ac.uk>	<20050331070514.GH9204@suse.de>
	<20050331071043.GI9204@suse.de>	<63537e2b84ddbba6cb3d970f73c6ab35@cl.cam.ac.uk>	<20050331081900.GK9204@suse.de>	<20050331143312.GB13179@vienna.egenera.com>	<20050331153449.GE12579@tpkurt.garloff.de>	<20050331153925.GP9204@suse.de>
	<20050331154130.GQ9204@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <20050331154130.GQ9204@suse.de>
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: Jens Axboe <axboe@suse.de>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, Xen development list <xen-devel@lists.xensource.com>, Kurt Garloff <garloff@suse.de>, Philip R Auld <pauld@egenera.com>, Vincent Hanquez <tab@snarc.org>, Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
List-Id: xen-devel@lists.xenproject.org

Jens Axboe wrote:

> There are still cases where it will be suboptimal of course, I didn't
> intend to claim it will always be as fast as queue tracking! If you are
> unlucky enough that the first request will reach the target device and
> get started before the next one, you will have a small and a large part
> of any given request executed. This isn't good for performance,
> naturally. But queueing is so fast, I would be surprised if this
> happened much in the real world.

Although the usual answer for what scheduling algorithm is
best is almost always "depends on the workload", it was
suggested to me that the cfq was still the best option to
go with. What do people feel about that? (Or is AS going
to remain default?).

Also, we're making the assumption here that guest OS = virtual
driver/device. I would rather we not make that assumption
always. This may be moot because I was also told there might
be a patch floating around (-mm ?) that allows you to
select scheduling algorithm on a per-device basis. Anyone
know if this is going to come in anytime soon?

thanks,
Nivedita