All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dongsu Park <dongsu.park@profitbricks.com>
To: Martin Mailand <martin@tuxadero.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, stefanha@gmail.com
Subject: Re: virtio-blk performance regression and qemu-kvm
Date: Tue, 6 Mar 2012 15:32:00 +0100	[thread overview]
Message-ID: <20120306143200.GB4053@gmail.com> (raw)
In-Reply-To: <4F54E620.8060400@tuxadero.com>

Hi Martin,

On 05.03.2012 17:13, Martin Mailand wrote:
> Am 10.02.2012 15:36, schrieb Dongsu Park:
> >Recently I observed performance regression regarding virtio-blk,
> >especially different IO bandwidths between qemu-kvm 0.14.1 and 1.0.
> >So I want to share the benchmark results, and ask you what the reason
> >would be.
> 
> 
> Hi,
> I think I found the problem, there is no regression in the code.
> I think the problem is, that qmeu-kvm with the IO-Thread enabled
> doesn't produce enough cpu load to get the core to a higher cpu
> frequency, because the load is distributed to two threads.
> If I change the cpu governor to "performance" the result from the
> master branch is better than from the v0.14.1 branch.
> I get the same results on a serversystem without powermanagment activated.
> 
> @Dongsu Could you confirm those findings?

Yes, I can confirm that.
I just tested with different CPU governor configs, "ondemand" and 
"performance". (qemu-kvm 1.0, AMD Phenom II X4 955)

The result is more or less like yours.
Bandwidth with "performance" gets more than 100% better than that with
"ondemand".
That looks definitely one of the reasons of regressions I experienced.
Actually I had always tested with "ondemand", which I haven't noticed.
 
Good catch, thanks!
Dongsu


> 1. Test on i7 Laptop with Cpu governor "ondemand".
> 
> v0.14.1
> bw=63492KB/s iops=15873
> bw=63221KB/s iops=15805
> 
> v1.0
> bw=36696KB/s iops=9173
> bw=37404KB/s iops=9350
> 
> master
> bw=36396KB/s iops=9099
> bw=34182KB/s iops=8545
> 
> Change the Cpu governor to "performance"
> master
> bw=81756KB/s iops=20393
> bw=81453KB/s iops=20257
> 
> 
> 2. Test on AMD Istanbul without powermanagement activated.
> 
> v0.14.1
> bw=53167KB/s iops=13291
> bw=61386KB/s iops=15346
> 
> v1.0
> bw=43599KB/s iops=10899
> bw=46288KB/s iops=11572
> 
> master
> bw=60678KB/s iops=15169
> bw=62733KB/s iops=15683
> 
> -martin

WARNING: multiple messages have this Message-ID (diff)
From: Dongsu Park <dongsu.park@profitbricks.com>
To: Martin Mailand <martin@tuxadero.com>
Cc: stefanha@gmail.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] virtio-blk performance regression and qemu-kvm
Date: Tue, 6 Mar 2012 15:32:00 +0100	[thread overview]
Message-ID: <20120306143200.GB4053@gmail.com> (raw)
In-Reply-To: <4F54E620.8060400@tuxadero.com>

Hi Martin,

On 05.03.2012 17:13, Martin Mailand wrote:
> Am 10.02.2012 15:36, schrieb Dongsu Park:
> >Recently I observed performance regression regarding virtio-blk,
> >especially different IO bandwidths between qemu-kvm 0.14.1 and 1.0.
> >So I want to share the benchmark results, and ask you what the reason
> >would be.
> 
> 
> Hi,
> I think I found the problem, there is no regression in the code.
> I think the problem is, that qmeu-kvm with the IO-Thread enabled
> doesn't produce enough cpu load to get the core to a higher cpu
> frequency, because the load is distributed to two threads.
> If I change the cpu governor to "performance" the result from the
> master branch is better than from the v0.14.1 branch.
> I get the same results on a serversystem without powermanagment activated.
> 
> @Dongsu Could you confirm those findings?

Yes, I can confirm that.
I just tested with different CPU governor configs, "ondemand" and 
"performance". (qemu-kvm 1.0, AMD Phenom II X4 955)

The result is more or less like yours.
Bandwidth with "performance" gets more than 100% better than that with
"ondemand".
That looks definitely one of the reasons of regressions I experienced.
Actually I had always tested with "ondemand", which I haven't noticed.
 
Good catch, thanks!
Dongsu


> 1. Test on i7 Laptop with Cpu governor "ondemand".
> 
> v0.14.1
> bw=63492KB/s iops=15873
> bw=63221KB/s iops=15805
> 
> v1.0
> bw=36696KB/s iops=9173
> bw=37404KB/s iops=9350
> 
> master
> bw=36396KB/s iops=9099
> bw=34182KB/s iops=8545
> 
> Change the Cpu governor to "performance"
> master
> bw=81756KB/s iops=20393
> bw=81453KB/s iops=20257
> 
> 
> 2. Test on AMD Istanbul without powermanagement activated.
> 
> v0.14.1
> bw=53167KB/s iops=13291
> bw=61386KB/s iops=15346
> 
> v1.0
> bw=43599KB/s iops=10899
> bw=46288KB/s iops=11572
> 
> master
> bw=60678KB/s iops=15169
> bw=62733KB/s iops=15683
> 
> -martin

  parent reply	other threads:[~2012-03-06 14:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10 14:36 virtio-blk performance regression and qemu-kvm Dongsu Park
2012-02-10 14:36 ` [Qemu-devel] " Dongsu Park
2012-02-12 23:55 ` Rusty Russell
2012-02-12 23:55   ` [Qemu-devel] " Rusty Russell
2012-02-21 16:45   ` Dongsu Park
2012-02-21 16:45     ` [Qemu-devel] " Dongsu Park
2012-02-21 22:16     ` Rusty Russell
2012-02-21 22:16       ` [Qemu-devel] " Rusty Russell
2012-02-13 11:57 ` Stefan Hajnoczi
2012-02-13 11:57   ` [Qemu-devel] " Stefan Hajnoczi
2012-02-21 15:57   ` Dongsu Park
2012-02-21 15:57     ` [Qemu-devel] " Dongsu Park
2012-02-21 17:27     ` Stefan Hajnoczi
2012-02-21 17:27       ` [Qemu-devel] " Stefan Hajnoczi
2012-02-22 16:48       ` Dongsu Park
2012-02-22 16:48         ` [Qemu-devel] " Dongsu Park
2012-02-22 19:53         ` Stefan Hajnoczi
2012-02-22 19:53           ` [Qemu-devel] " Stefan Hajnoczi
2012-02-28 16:39           ` Martin Mailand
2012-02-28 16:39             ` [Qemu-devel] " Martin Mailand
2012-02-28 17:05             ` Stefan Hajnoczi
2012-02-28 17:05               ` [Qemu-devel] " Stefan Hajnoczi
2012-02-28 17:15               ` Martin Mailand
2012-02-28 17:15                 ` [Qemu-devel] " Martin Mailand
2012-02-29  8:38                 ` Stefan Hajnoczi
2012-02-29  8:38                   ` [Qemu-devel] " Stefan Hajnoczi
2012-02-29 13:12                   ` Martin Mailand
2012-02-29 13:12                     ` [Qemu-devel] " Martin Mailand
2012-02-29 13:44                     ` Stefan Hajnoczi
2012-02-29 13:44                       ` [Qemu-devel] " Stefan Hajnoczi
2012-02-29 13:52                       ` Stefan Hajnoczi
2012-02-29 13:52                         ` [Qemu-devel] " Stefan Hajnoczi
2012-03-05 16:13 ` Martin Mailand
2012-03-05 16:13   ` [Qemu-devel] " Martin Mailand
2012-03-05 16:35   ` Stefan Hajnoczi
2012-03-05 16:35     ` [Qemu-devel] " Stefan Hajnoczi
2012-03-05 16:44     ` Martin Mailand
2012-03-05 16:44       ` [Qemu-devel] " Martin Mailand
2012-03-06 12:59       ` Stefan Hajnoczi
2012-03-06 12:59         ` [Qemu-devel] " Stefan Hajnoczi
2012-03-06 22:07         ` Reeted
2012-03-06 22:07           ` Reeted
2012-03-07  8:04           ` Stefan Hajnoczi
2012-03-07 14:21             ` Reeted
2012-03-07 14:33               ` Stefan Hajnoczi
2012-03-07 14:33                 ` Stefan Hajnoczi
2012-03-07 10:39         ` Martin Mailand
2012-03-07 10:39           ` [Qemu-devel] " Martin Mailand
2012-03-07 11:21           ` Paolo Bonzini
2012-03-07 11:21             ` [Qemu-devel] " Paolo Bonzini
2012-03-06 14:32   ` Dongsu Park [this message]
2012-03-06 14:32     ` Dongsu Park

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=20120306143200.GB4053@gmail.com \
    --to=dongsu.park@profitbricks.com \
    --cc=kvm@vger.kernel.org \
    --cc=martin@tuxadero.com \
    --cc=qemu-devel@nongnu.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.