All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhang Haoyu <ahzhanghaoyu@gmail.com>
To: Zhang Haoyu <zhanghy@sangfor.com>,
	Amit Shah <amit.shah@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [question] virtio-blk performance degradation happened with virito-serial
Date: Tue, 16 Sep 2014 22:59:49 +0800	[thread overview]
Message-ID: <54185065.8090004@gmail.com> (raw)
In-Reply-To: <201409121121358332189@sangfor.com>

>>>>>> If virtio-blk and virtio-serial share an IRQ, the guest operating
system has to check each virtqueue for activity. Maybe there is some
inefficiency doing that.
>>>>>> AFAIK virtio-serial registers 64 virtqueues (on 31 ports +
console) even if everything is unused.
>>>>>
>>>>> That could be the case if MSI is disabled.
>>>>
>>>> Do the windows virtio drivers enable MSIs, in their inf file?
>>>
>>> It depends on the version of the drivers, but it is a reasonable guess
>>> at what differs between Linux and Windows. Haoyu, can you give us the
>>> output of lspci from a Linux guest?
>>>
>> I made a test with fio on rhel-6.5 guest, the same degradation
happened too, this degradation can be reproduced on rhel6.5 guest 100%.
>> virtio_console module installed:
>> 64K-write-sequence: 285 MBPS, 4380 IOPS
>> virtio_console module uninstalled:
>> 64K-write-sequence: 370 MBPS, 5670 IOPS
>>
>I use top -d 1 -H -p <qemu-pid> to monitor the cpu usage, and found that,
>virtio_console module installed:
>qemu main thread cpu usage: 98%
>virtio_console module uninstalled:
>qemu main thread cpu usage: 60%
>

I found that the statement "err =
register_virtio_driver(&virtio_console);" in virtio_console module's
init() function will
cause the degradation, if I directly return before "err =
register_virtio_driver(&virtio_console);", then the degradation disappeared,
if directly return after "err =
register_virtio_driver(&virtio_console);", the degradation is still there.
I will try below test case,
1. Dose not emulate virito-serial deivce, then install/uninstall
virtio_console driver in guest,
to see whether there is difference in virtio-blk performance and cpu usage.
2. Does not emulate virito-serial deivce, then install virtio_balloon
driver (and also dose not emulate virtio-balloon device),
to see whether virtio-blk performance degradation will happen.
3. Emulating virtio-balloon device instead of virtio-serial deivce ,
then to see whether the virtio-blk performance is hampered.

Base on the test result, corresponding analysis will be performed.
Any ideas?

Thanks,
Zhang Haoyu

WARNING: multiple messages have this Message-ID (diff)
From: Zhang Haoyu <ahzhanghaoyu@gmail.com>
To: Zhang Haoyu <zhanghy@sangfor.com>,
	Amit Shah <amit.shah@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [question] virtio-blk performance degradation happened with virito-serial
Date: Tue, 16 Sep 2014 22:59:49 +0800	[thread overview]
Message-ID: <54185065.8090004@gmail.com> (raw)
In-Reply-To: <201409121121358332189@sangfor.com>

>>>>>> If virtio-blk and virtio-serial share an IRQ, the guest operating
system has to check each virtqueue for activity. Maybe there is some
inefficiency doing that.
>>>>>> AFAIK virtio-serial registers 64 virtqueues (on 31 ports +
console) even if everything is unused.
>>>>>
>>>>> That could be the case if MSI is disabled.
>>>>
>>>> Do the windows virtio drivers enable MSIs, in their inf file?
>>>
>>> It depends on the version of the drivers, but it is a reasonable guess
>>> at what differs between Linux and Windows. Haoyu, can you give us the
>>> output of lspci from a Linux guest?
>>>
>> I made a test with fio on rhel-6.5 guest, the same degradation
happened too, this degradation can be reproduced on rhel6.5 guest 100%.
>> virtio_console module installed:
>> 64K-write-sequence: 285 MBPS, 4380 IOPS
>> virtio_console module uninstalled:
>> 64K-write-sequence: 370 MBPS, 5670 IOPS
>>
>I use top -d 1 -H -p <qemu-pid> to monitor the cpu usage, and found that,
>virtio_console module installed:
>qemu main thread cpu usage: 98%
>virtio_console module uninstalled:
>qemu main thread cpu usage: 60%
>

I found that the statement "err =
register_virtio_driver(&virtio_console);" in virtio_console module's
init() function will
cause the degradation, if I directly return before "err =
register_virtio_driver(&virtio_console);", then the degradation disappeared,
if directly return after "err =
register_virtio_driver(&virtio_console);", the degradation is still there.
I will try below test case,
1. Dose not emulate virito-serial deivce, then install/uninstall
virtio_console driver in guest,
to see whether there is difference in virtio-blk performance and cpu usage.
2. Does not emulate virito-serial deivce, then install virtio_balloon
driver (and also dose not emulate virtio-balloon device),
to see whether virtio-blk performance degradation will happen.
3. Emulating virtio-balloon device instead of virtio-serial deivce ,
then to see whether the virtio-blk performance is hampered.

Base on the test result, corresponding analysis will be performed.
Any ideas?

Thanks,
Zhang Haoyu

  parent reply	other threads:[~2014-09-16 14:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29  7:45 [question] virtio-blk performance degradation happened with virito-serial Zhang Haoyu
2014-08-29  7:45 ` [Qemu-devel] " Zhang Haoyu
2014-08-29 14:38 ` Amit Shah
2014-09-01 12:38   ` [Qemu-devel] [question] virtio-blk performance degradationhappened " Zhang Haoyu
2014-09-01 12:46     ` Amit Shah
2014-09-01 12:57       ` [Qemu-devel] [question] virtio-blk performancedegradationhappened " Zhang Haoyu
2014-09-01 12:52     ` [Qemu-devel] [question] virtio-blk performance degradationhappened " Zhang Haoyu
2014-09-01 13:09       ` Christian Borntraeger
2014-09-01 13:12         ` Paolo Bonzini
2014-09-01 13:22           ` Christian Borntraeger
2014-09-01 13:29             ` Paolo Bonzini
2014-09-01 14:03               ` Christian Borntraeger
2014-09-01 14:15                 ` Christian Borntraeger
2014-09-04  7:56             ` [Qemu-devel] [question] virtio-blk performance degradationhappenedwith virito-serial Zhang Haoyu
2014-09-07  9:46               ` Zhang Haoyu
2014-09-07  9:46                 ` Zhang Haoyu
2014-09-11  6:11                 ` Amit Shah
2014-09-11  6:11                   ` Amit Shah
2014-09-12  3:21                   ` [question] virtio-blk performance degradation happened with virito-serial Zhang Haoyu
2014-09-12  3:21                     ` [Qemu-devel] " Zhang Haoyu
2014-09-12 12:38                     ` Stefan Hajnoczi
2014-09-12 12:38                       ` Stefan Hajnoczi
2014-09-13 17:22                       ` Max Reitz
2014-09-13 17:22                         ` Max Reitz
2014-09-16 14:59                     ` Zhang Haoyu [this message]
2014-09-16 14:59                       ` Zhang Haoyu
2014-09-02  6:36       ` [Qemu-devel] [question] virtio-blk performance degradationhappened " Amit Shah
2014-09-02 18:05         ` Andrey Korolyov
2014-09-02 18:11           ` Amit Shah
2014-09-02 18:11             ` [Qemu-devel] " Amit Shah
2014-09-02 18:27             ` Andrey Korolyov
2014-09-04  2:20         ` [Qemu-devel] [question] virtio-blk performancedegradationhappened " Zhang Haoyu
2014-09-19  5:53         ` [Qemu-devel] [question] virtio-blk performance degradationhappened " Fam Zheng
2014-09-19  5:53           ` Fam Zheng
2014-09-19 13:35           ` Paolo Bonzini
2014-09-19 13:35             ` [Qemu-devel] " Paolo Bonzini
2014-09-22 13:23           ` [Qemu-devel] [question] virtio-blk performancedegradationhappened " Zhang Haoyu
2014-09-22 13:23             ` Zhang Haoyu
2014-09-23  1:29             ` Fam Zheng
2014-09-23  1:29               ` Fam Zheng

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=54185065.8090004@gmail.com \
    --to=ahzhanghaoyu@gmail.com \
    --cc=amit.shah@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhanghy@sangfor.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.