All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Rozenfeld <vrozenfe@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: George Bottas <gbottas@juniper.net>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Virtio Block Device Queue Depth
Date: Sat, 10 Mar 2012 02:10:02 +0200	[thread overview]
Message-ID: <201203100210.03415.vrozenfe@redhat.com> (raw)
In-Reply-To: <CAJSP0QVK-mqJ0gdgA5KmOm7EA_DBxf_8Q4Rk0hpV2DcJ1pQKeQ@mail.gmail.com>

On Friday, March 09, 2012 11:56:36 AM you wrote:
> On Thu, Mar 8, 2012 at 5:48 PM, George Bottas <gbottas@juniper.net> wrote:
> > I have a question regarding changing the queue size that is set in
> > virtio_blk_init(). The current value is 128, which results in setting
> > the queue depth in the Windows guest device to 8. Does anyone know if
Actually, it's 6 128/(16+1) - 1
> > changing this value to defined maximum (1024) going to result in any
In my experience, enalarging the queueu size doen't leas to any 
significant performance improvement 
> > issues? NB, we have also increased the thread pool accordingly. Our
> > testing so far has produced a situation where initially we are seeing
> > very high read request rates (1500+), and then at some point the reads
> > from the Windows guest become serialized, i.e. the Windows guest
> > synchronously sends one READ to the host, waits for it to complete,
> > sends the next one, etc.  Has this ever been seen anywhere else?
On Win2K3 and higher, viostor operats in full-duplex mode. Which means
that it must be able to process several requests simulteniousle. But
if you have 6 requests pending (processing), storport driver will throttle
incomming requestss. 
> > 
> > Any help on this would be appreciated.
> 
> If you are really limited to 8 requests then the issue is not the
> number of vring descriptors since recent virtio-blk has the indirect
> vring feature enabled.  The indirect vring feature allows the guest to
> send 128 parallel requests - much higher than the 8 you mentioned from
> Windows.
It's true. However, I cannot say that indirect buffers will automaticaly
give you a better performance. Inderect buffers should work faster for
peretty big data chanks (128K..256K), while for the normal load (4K..64K)
they give you almost the same numbers. 
Vadim.
> 
> CCing Vadim who maintains the Windows virtio-blk driver.
> 
> Stefan

      reply	other threads:[~2012-03-10  0:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08 17:48 Virtio Block Device Queue Depth George Bottas
2012-03-09  9:56 ` Stefan Hajnoczi
2012-03-10  0:10   ` Vadim Rozenfeld [this message]

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=201203100210.03415.vrozenfe@redhat.com \
    --to=vrozenfe@redhat.com \
    --cc=gbottas@juniper.net \
    --cc=kvm@vger.kernel.org \
    --cc=stefanha@gmail.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.