Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] poor domU VBD performance.
From: Jens Axboe <axboe@xxxxxxx>
Date: Thu, 31 Mar 2005 21:20:10 +0200
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Philip R Auld <pauld@xxxxxxxxxxx>, Kurt Garloff <garloff@xxxxxxx>, Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Vincent Hanquez <tab@xxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Thu, 31 Mar 2005 19:20:18 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f2ccf7f627278ae1b5169fae8bc21eda@xxxxxxxxxxxx>
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>
References: <20050331070514.GH9204@xxxxxxx> <20050331071043.GI9204@xxxxxxx> <63537e2b84ddbba6cb3d970f73c6ab35@xxxxxxxxxxxx> <20050331081900.GK9204@xxxxxxx> <20050331143312.GB13179@xxxxxxxxxxxxxxxxxx> <20050331153449.GE12579@xxxxxxxxxxxxxxxxx> <20050331165305.GA13875@xxxxxxxxxxxxxxxxxx> <20050331180151.GT9204@xxxxxxx> <20050331184309.GC13875@xxxxxxxxxxxxxxxxxx> <f2ccf7f627278ae1b5169fae8bc21eda@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Mar 31 2005, Keir Fraser wrote:
> >What I was getting at was that the backend  will split requests
> >up and issue each physical segment as a separate bio  (at least in
> >the 2.0.5 tree I have in front of me). And that none of these
> >physical segments was more that 1 page.
> >
> >So the request merging in the back end OS is important, no?
> 
> Ah, this reminds me I have one more question for Jens.
> 
> Since all the bio's that I queue up in a single invocation of 
> dispatch_rw_block_io() will actually be adjacent to each other (because 
> they're all from the same scatter-gather list) can I actually do 
> something like (very roughly):
> 
> bio = bio_alloc(GFP_KERNEL, nr_psegs);
> for ( i = 0; i < nr_psegs; i++ )
>    bio_add_page(bio, blah...);
> submit_bio(operation, bio);
> 
> Each of the biovecs that I queue may not be a full page in size (but 
> won't straddle a page boundary of course).

Yes, this is precisely what you should do, the current method is pretty
suboptimal. Basically allocate a bio with nr_psegs, and call
bio_add_page() for each page until it returns _less_ than the number of
bytes you requested. When it does that, submit that bio for io and
allocate a new bio with nr_psegs-submitted_segs bio_vecs attached.
Continue until you are done.

-- 
Jens Axboe


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