Am 06.03.2012 13:59, schrieb Stefan Hajnoczi:
Yes, the reason why that would be interesting is because it allows us
to put the performance gain with master+"performance" into
perspective. We could see how much of a change we get.
Does the CPU governor also affect the result when you benchmark w
Am 05.03.2012 17:35, schrieb Stefan Hajnoczi:
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
>
> Ch
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
Hi Stefan,
you are right, the performance for the commits 0b9b128530b and
4fefc55ab04d are both good.
What is the best approach to stay in the qemu-kvm.git history?
-martin
On 29.02.2012 09:38, Stefan Hajnoczi wrote:
I suggest testing both of the qemu-kvm.git merge commits, 0b9b128530b
and 4f
9bc1] trace: fix
out-of-tree builds
git bisect good d9cd446b4f6ff464f9520898116534de988d9bc1
# bad: [12d4536f7d911b6d87a766ad7300482ea663cea2] main: force enabling
of I/O thread
git bisect bad 12d4536f7d911b6d87a766ad7300482ea663cea2
-martin
On 28.02.2012 18:05, Stefan Hajnoczi wrote:
On Tu
Hi,
I could reproduce it and I bisected it down to this commit.
12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
commit 12d4536f7d911b6d87a766ad7300482ea663cea2
Author: Anthony Liguori
Date: Mon Aug 22 08:24:58 2011 -0500
-martin
On 22.02.2012 20:53, Stefan Hajnoczi wrote:
