From: "Michael S. Tsirkin" <mst@redhat.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org
Subject: [Qemu-devel] Re: [RFC] vhost-blk implementation
Date: Wed, 24 Mar 2010 11:52:21 +0200 [thread overview]
Message-ID: <20100324095221.GA7622@redhat.com> (raw)
In-Reply-To: <4BA91C9B.8070900@us.ibm.com>
On Tue, Mar 23, 2010 at 12:55:07PM -0700, Badari Pulavarty wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Mar 23, 2010 at 10:57:33AM -0700, Badari Pulavarty wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
>>>> On Mon, Mar 22, 2010 at 05:34:04PM -0700, Badari Pulavarty wrote:
>>>>
>>>>> Write Results:
>>>>> ==============
>>>>>
>>>>> I see degraded IO performance when doing sequential IO write
>>>>> tests with vhost-blk compared to virtio-blk.
>>>>>
>>>>> # time dd of=/dev/vda if=/dev/zero bs=2M oflag=direct
>>>>>
>>>>> I get ~110MB/sec with virtio-blk, but I get only ~60MB/sec with
>>>>> vhost-blk. Wondering why ?
>>>>>
>>>> Try to look and number of interrupts and/or number of exits.
>>>>
>>> I checked interrupts and IO exits - there is no major noticeable
>>> difference between
>>> vhost-blk and virtio-blk scenerios.
>>>
>>>> It could also be that you are overrunning some queue.
>>>>
>>>> I don't see any exit mitigation strategy in your patch:
>>>> when there are already lots of requests in a queue, it's usually
>>>> a good idea to disable notifications and poll the
>>>> queue as requests complete. That could help performance.
>>>>
>>> Do you mean poll eventfd for new requests instead of waiting for new
>>> notifications ?
>>> Where do you do that in vhost-net code ?
>>>
>>
>> vhost_disable_notify does this.
>>
>>
>>> Unlike network socket, since we are dealing with a file, there is no
>>> ->poll support for it.
>>> So I can't poll for the data. And also, Issue I am having is on the
>>> write() side.
>>>
>>
>> Not sure I understand.
>>
>>
>>> I looked at it some more - I see 512K write requests on the
>>> virtio-queue in both vhost-blk and virtio-blk cases. Both qemu or
>>> vhost is doing synchronous writes to page cache (there is no write
>>> batching in qemu that is affecting this case). I still puzzled on
>>> why virtio-blk outperforms vhost-blk.
>>>
>>> Thanks,
>>> Badari
>>>
>>
>> If you say the number of requests is the same, we are left with:
>> - requests are smaller for some reason?
>> - something is causing retries?
>>
> No. IO requests sizes are exactly same (512K) in both cases. There are
> no retries or
> errors in both cases. One thing I am not clear is - for some reason
> guest kernel
> could push more data into virtio-ring in case of virtio-blk vs
> vhost-blk. Is this possible ?
> Does guest gets to run much sooner in virtio-blk case than vhost-blk ?
> Sorry, if its dumb question -
> I don't understand all the vhost details :(
>
> Thanks,
> Badari
>
You said you observed same number of requests in userspace versus kernel above.
And request size is the same as well. But somehow more data is
transferred? I'm confused.
--
MST
next prev parent reply other threads:[~2010-03-24 9:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 0:34 [Qemu-devel] [RFC] vhost-blk implementation Badari Pulavarty
2010-03-23 12:39 ` [Qemu-devel] " Michael S. Tsirkin
2010-03-23 14:47 ` Badari Pulavarty
2010-03-23 17:57 ` Badari Pulavarty
2010-03-23 18:06 ` Michael S. Tsirkin
2010-03-23 19:55 ` Badari Pulavarty
2010-03-24 9:52 ` Michael S. Tsirkin [this message]
2010-03-24 11:23 ` Michael S. Tsirkin
2010-03-24 17:58 ` Badari Pulavarty
2010-03-24 18:28 ` Michael S. Tsirkin
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=20100324095221.GA7622@redhat.com \
--to=mst@redhat.com \
--cc=pbadari@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).