WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: RE: RE: [Xen-devel] poor domU VBD performance.

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: RE: RE: [Xen-devel] poor domU VBD performance.
From: Kurt Garloff <garloff@xxxxxxx>
Date: Wed, 30 Mar 2005 00:45:03 +0200
Cc: Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Vincent Hanquez <tab@xxxxxxxxx>, Jens Axboe <axboe@xxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Tue, 29 Mar 2005 22:45:16 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3905@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: SUSE/Novell
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3905@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6i
Hi Ian,

On Tue, Mar 29, 2005 at 07:09:50PM +0100, Ian Pratt wrote:
> We'd really appreciate your help on this, or from someone else at SuSE
> who actually understands the Linux block layer?

I'm Cc'ing Jens ...
 
> In the 2.6 blkfront driver, what scheduler should we be registering
> with? What should we be setting as max_sectors? Are there other
> parameters we should be setting that we aren't? (block size?)

I think noop is a good choice for secondary domains, as you don't
want to be too clever there, otherwise you stack a clever scheduler
on top of a clever scheduler. noop basically only does front- and
backmerging to make the request sizes larger.

But you probably should initialize the readahead sectors.

Please test attached patch.

It fixed the problem for me, but my testing was very limited,
I only had a small loopback mounted root fs to test with quickly.

Note that initializing to 256 (128k) would be OK as well (and might 
be the better default); it seems to be set to 256 (128k) by default, 
but it's not ... If you explicitly set it to 256, the performance 
still increases tremendously.

> In the blkback driver that actually issues the IO's in dom0, is there
> something we should be doing to cause IOs to get batched? In 2.4 we used
> a task_queue to push the IO through to the disk having queued it with
> generic_make_request(). In 2.6 we're currently using submit_bio() and
> just hoping that batching happens.

I don't think the blkback driver does anything wrong here.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

Attachment: xen-blkfront-ra.diff
Description: Text document

Attachment: pgpwBqlhag3Wi.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel