From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jens Axboe <axboe@suse.de>
Subject: Re: poor domU VBD performance.
Date: Thu, 31 Mar 2005 21:20:10 +0200
Message-ID: <20050331192009.GV9204@suse.de>
References: <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>
	<20050331165305.GA13875@vienna.egenera.com>
	<20050331180151.GT9204@suse.de>
	<20050331184309.GC13875@vienna.egenera.com>
	<f2ccf7f627278ae1b5169fae8bc21eda@cl.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <f2ccf7f627278ae1b5169fae8bc21eda@cl.cam.ac.uk>
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: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>, Philip R Auld <pauld@egenera.com>, Kurt Garloff <garloff@suse.de>, Xen development list <xen-devel@lists.xensource.com>, Vincent Hanquez <tab@snarc.org>, Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
List-Id: xen-devel@lists.xenproject.org

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