From: Jens Axboe <axboe@suse.de>
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>
Subject: Re: poor domU VBD performance.
Date: Thu, 31 Mar 2005 21:20:10 +0200 [thread overview]
Message-ID: <20050331192009.GV9204@suse.de> (raw)
In-Reply-To: <f2ccf7f627278ae1b5169fae8bc21eda@cl.cam.ac.uk>
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
next prev parent reply other threads:[~2005-03-31 19:20 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-30 11:16 RE: RE: poor domU VBD performance Ian Pratt
2005-03-30 17:01 ` peter bier
2005-03-30 18:05 ` Andrew Theurer
2005-03-31 7:05 ` RE: " Jens Axboe
2005-03-31 7:10 ` Jens Axboe
2005-03-31 8:17 ` Keir Fraser
2005-03-31 8:19 ` Jens Axboe
2005-03-31 14:33 ` Philip R Auld
2005-03-31 15:34 ` Kurt Garloff
2005-03-31 15:39 ` Jens Axboe
2005-03-31 15:41 ` Jens Axboe
2005-03-31 16:27 ` Nivedita Singhvi
2005-03-31 17:43 ` Jens Axboe
2005-03-31 18:27 ` Kurt Garloff
2005-03-31 21:59 ` Nivedita Singhvi
2005-03-31 15:49 ` Keir Fraser
2005-03-31 16:02 ` Andrew Theurer
2005-03-31 17:44 ` Jens Axboe
2005-03-31 16:55 ` Philip R Auld
2005-03-31 16:53 ` Philip R Auld
2005-03-31 18:01 ` Jens Axboe
2005-03-31 18:43 ` Philip R Auld
2005-03-31 19:07 ` Keir Fraser
2005-03-31 19:10 ` Keir Fraser
2005-03-31 19:20 ` Jens Axboe [this message]
2005-03-31 19:21 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2005-04-04 19:36 Ian Pratt
2005-04-04 22:35 ` Nicholas Lee
2005-04-12 10:29 ` peter bier
2005-04-02 10:56 Ian Pratt
2005-04-02 12:10 ` Cédric Schieli
2005-04-01 23:22 Ian Pratt
2005-04-02 10:36 ` Cédric Schieli
2005-04-02 19:54 ` peter bier
2005-03-31 22:36 Ian Pratt
2005-03-31 23:05 ` Andrew Theurer
2005-04-01 21:40 ` Cédric Schieli
2005-03-31 21:32 Ian Pratt
2005-03-31 22:13 ` Andrew Theurer
2005-03-31 17:55 Ian Pratt
2005-03-31 18:04 ` Jens Axboe
2005-03-31 18:57 ` Keir Fraser
2005-03-31 19:22 ` Jens Axboe
2005-03-31 20:49 ` Andrew Theurer
2005-03-31 21:15 ` Keir Fraser
2005-03-31 21:27 ` Andrew Theurer
2005-04-01 5:43 ` Jens Axboe
2005-04-01 16:36 ` peter bier
[not found] <A95E2296287EAD4EB592B5DEEFCE0E9D1E3905@liverpoolst.ad.cl.cam.ac.uk>
2005-03-29 22:45 ` RE: " Kurt Garloff
2005-03-29 22:59 ` Andrew Theurer
2005-03-29 23:19 ` Kurt Garloff
2005-03-29 23:26 ` Andrew Theurer
2005-03-29 14:19 Ian Pratt
2005-03-29 15:27 ` peter bier
2005-03-28 22:17 Ian Pratt
2005-03-29 8:44 ` peter bier
2005-03-28 20:14 Ian Pratt
2005-03-28 20:18 ` Andrew Theurer
2005-03-28 21:48 ` Andrew Theurer
2005-03-28 23:38 ` Peter Bier
2005-03-29 0:27 ` Andrew Theurer
2005-03-29 11:39 ` peter bier
2005-03-28 18:55 Ian Pratt
2005-03-28 19:33 ` Andrew Theurer
2005-03-27 17:41 Ian Pratt
2005-03-28 8:48 ` peter bier
2005-03-28 12:44 ` peter bier
2005-03-29 6:20 ` Pasi Kärkkäinen
2005-03-26 18:14 Peter Bier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050331192009.GV9204@suse.de \
--to=axboe@suse.de \
--cc=Christian.Limpach@cl.cam.ac.uk \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=garloff@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=pauld@egenera.com \
--cc=tab@snarc.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.