All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: Xen development list <xen-devel@lists.xensource.com>,
	Kurt Garloff <garloff@suse.de>, Vincent Hanquez <tab@snarc.org>,
	Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Subject: Re: RE: RE: poor domU VBD performance.
Date: Thu, 31 Mar 2005 09:10:43 +0200	[thread overview]
Message-ID: <20050331071043.GI9204@suse.de> (raw)
In-Reply-To: <20050331070514.GH9204@suse.de>

On Thu, Mar 31 2005, Jens Axboe wrote:
> On Wed, Mar 30 2005, Ian Pratt wrote:
> > > I'll check the xen block driver to see if there's anything 
> > > else that sticks out.
> > >
> > > Jens Axboe
> > 
> > Jens, I'd really appreciate this.
> > 
> > The blkfront/blkback drivers have rather evolved over time, and I don't
> > think any of the core team fully understand the block-layer differences
> > between 2.4 and 2.6. 
> > 
> > There's also some junk left in there from when the backend was in Xen
> > itself back in the days of 1.2, though Vincent has prepared a patch to
> > clean this up and also make 'refreshing' of vbd's work (for size
> > changes), and also allow the blkfront driver to import whole disks
> > rather than paritions. We had this functionality on 2.4, but lost it in
> > the move to 2.6.
> > 
> > My bet is that it's the 2.6 backend that is where the true perofrmance
> > bug lies. Using a 2.6 domU blkfront talking to a 2.4 dom0 blkback seems
> > to give good performance under a wide variety of circumstances. Using a
> > 2.6 dom0 is far more pernickety. I agree with Andrew that I suspect it's
> > the work queue changes are biting us when we don't have many outstanding
> > requests.
> 
> You never schedule the queues you submit the io against for the 2.6
> kernel, you only have a tq_disk run for 2.4 kernels. This basically puts
> you at the mercy of the timeout unplugging, which is really suboptimal
> unless you can keep the io queue of the target busy at all times.
> 
> You need to either mark the last bio going to that device as BIO_SYNC,
> or do a blk_run_queue() on the target queue after having submitted all
> io in this batch for it.

Here is a temporary work-around, this should bring you close to 100%
performance at the cost of some extra unplugs. Uncompiled.

--- blkback.c~	2005-03-31 09:06:16.000000000 +0200
+++ blkback.c	2005-03-31 09:09:27.000000000 +0200
@@ -481,7 +481,6 @@
     for ( i = 0; i < nr_psegs; i++ )
     {
         struct bio *bio;
-        struct bio_vec *bv;
 
         bio = bio_alloc(GFP_ATOMIC, 1);
         if ( unlikely(bio == NULL) )
@@ -494,17 +493,12 @@
         bio->bi_private = pending_req;
         bio->bi_end_io  = end_block_io_op;
         bio->bi_sector  = phys_seg[i].sector_number;
-        bio->bi_rw      = operation;
 
-        bv = bio_iovec_idx(bio, 0);
-        bv->bv_page   = virt_to_page(MMAP_VADDR(pending_idx, i));
-        bv->bv_len    = phys_seg[i].nr_sects << 9;
-        bv->bv_offset = phys_seg[i].buffer & ~PAGE_MASK;
+	bio_add_page(bio, virt_to_page(MMAP_VADDR(pending_idx, i)),
+			phys_seg[i].nr_sects << 9,
+			phys_seg[i].buffer & ~PAGE_MASK);
 
-        bio->bi_size    = bv->bv_len;
-        bio->bi_vcnt++;
-
-        submit_bio(operation, bio);
+        submit_bio(operation | (1 << BIO_RW_SYNC), bio);
     }
 #endif
 

-- 
Jens Axboe

  reply	other threads:[~2005-03-31  7:10 UTC|newest]

Thread overview: 29+ 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 [this message]
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
2005-03-31 19:21                   ` Jens Axboe
     [not found] <A95E2296287EAD4EB592B5DEEFCE0E9D1E3905@liverpoolst.ad.cl.cam.ac.uk>
2005-03-29 22:45 ` RE: " Kurt Garloff
2005-03-30  8:53   ` Jens Axboe
2005-03-30 10:00   ` Kurt Garloff

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=20050331071043.GI9204@suse.de \
    --to=axboe@suse.de \
    --cc=Christian.Limpach@cl.cam.ac.uk \
    --cc=garloff@suse.de \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --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.