On Wed, Mar 7, 2012 at 2:21 PM, Reeted wrote:
> On 03/07/12 09:04, Stefan Hajnoczi wrote:
>>
>> On Tue, Mar 6, 2012 at 10:07 PM, Reeted wrote:
>>>
>>> On 03/06/12 13:59, Stefan Hajnoczi wrote:
BTW, I'll take the opportunity to say that 15.8 or 20.3 k IOPS are very
low
figures
On 03/07/12 09:04, Stefan Hajnoczi wrote:
On Tue, Mar 6, 2012 at 10:07 PM, Reeted wrote:
On 03/06/12 13:59, Stefan Hajnoczi wrote:
BTW, I'll take the opportunity to say that 15.8 or 20.3 k IOPS are very low
figures compared to what I'd instinctively expect from a paravirtualized
block driver.
Il 07/03/2012 11:39, Martin Mailand ha scritto:
> The host disk can at max. 13K iops, in qemu I get at max 6,5K iops,
> that's around about 50% overhead. All the test were with 4k reads, so I
> think we are mostly latency bound.
For latency tests, running without ioeventfd could give slightly bett
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
On Tue, Mar 6, 2012 at 10:07 PM, Reeted wrote:
> On 03/06/12 13:59, Stefan Hajnoczi wrote:
>>
>> On Mon, Mar 5, 2012 at 4:44 PM, Martin Mailand
>> wrote:
>>>
>>> Am 05.03.2012 17:35, schrieb Stefan Hajnoczi:
>>>
> 1. Test on i7 Laptop with Cpu governor "ondemand".
>>
>> v0.14.1
>
On 03/06/12 13:59, Stefan Hajnoczi wrote:
On Mon, Mar 5, 2012 at 4:44 PM, Martin Mailand wrote:
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
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
On Mon, Mar 5, 2012 at 4:44 PM, Martin Mailand wrote:
> 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
>>> > b
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
On Mon, Mar 5, 2012 at 4:13 PM, 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 wh
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
On Wed, Feb 29, 2012 at 1:44 PM, Stefan Hajnoczi wrote:
> On Wed, Feb 29, 2012 at 1:12 PM, Martin Mailand wrote:
>> 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?
>
> I d
On Wed, Feb 29, 2012 at 1:12 PM, Martin Mailand wrote:
> 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?
I didn't know the answer so I asked on #git on freenode:
< charon> s
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
On Tue, Feb 28, 2012 at 5:15 PM, Martin Mailand wrote:
> Hi Stefan,
> I was bisecting qemu-kvm.git.
qemu-kvm.git regularly merges from qemu.git. The history of the
qemu-kvm.git repository is not linear because of these periodic merges
from the qemu.git tree. I think what happened is that git bi
Hi Stefan,
I was bisecting qemu-kvm.git.
git remote show origin
* remote origin
Fetch URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
Push URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
The bisect log is:
git bisect start
# good: [b8095f24f24e50a7d4be33d8a79474aff3324295]
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:
On Tue, Feb 28, 2012 at 4:39 PM, Martin Mailand wrote:
> 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
On Wed, Feb 22, 2012 at 4:48 PM, Dongsu Park
wrote:
>> Try turning ioeventfd off for the virtio-blk device:
>>
>> -device virtio-blk-pci,ioeventfd=off,...
>>
>> You might see better performance since ramdisk I/O should be very
>> low-latency. The overhead of using ioeventfd might not make it
>> w
Hi Stefan,
see below.
On 21.02.2012 17:27, Stefan Hajnoczi wrote:
> On Tue, Feb 21, 2012 at 3:57 PM, Dongsu Park
> wrote:
..
> I'm not sure if O_DIRECT and Linux AIO to /dev/ram0 is a good idea.
> At least with tmpfs O_DIRECT does not even work - which kind of makes
> sense there because tmp
On Tue, 21 Feb 2012 17:45:08 +0100, Dongsu Park
wrote:
> Hi Rusty,
>
> On 13.02.2012 10:25, Rusty Russell wrote:
> > On Fri, 10 Feb 2012 15:36:39 +0100, Dongsu Park
> > wrote:
> > > Hi,
> > >
> > > Recently I observed performance regression regarding virtio-blk,
> > > especially different IO
On Tue, Feb 21, 2012 at 3:57 PM, Dongsu Park
wrote:
> On 13.02.2012 11:57, Stefan Hajnoczi wrote:
>> On Fri, Feb 10, 2012 at 2:36 PM, Dongsu Park
>> wrote:
>> > Now I'm running benchmarks with both qemu-kvm 0.14.1 and 1.0.
>> >
>> > - Sequential read (Running inside guest)
>> > # fio -name io
Hi Rusty,
On 13.02.2012 10:25, Rusty Russell wrote:
> On Fri, 10 Feb 2012 15:36:39 +0100, Dongsu Park
> wrote:
> > Hi,
> >
> > 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 benc
Hi Stefan,
see below.
On 13.02.2012 11:57, Stefan Hajnoczi wrote:
> On Fri, Feb 10, 2012 at 2:36 PM, Dongsu Park
> wrote:
> > Now I'm running benchmarks with both qemu-kvm 0.14.1 and 1.0.
> >
> > - Sequential read (Running inside guest)
> > # fio -name iops -rw=read -size=1G -iodepth 1 \
> >
On Fri, Feb 10, 2012 at 2:36 PM, Dongsu Park
wrote:
> Now I'm running benchmarks with both qemu-kvm 0.14.1 and 1.0.
>
> - Sequential read (Running inside guest)
> # fio -name iops -rw=read -size=1G -iodepth 1 \
> -filename /dev/vdb -ioengine libaio -direct=1 -bs=4096
>
> - Sequential write
On Fri, 10 Feb 2012 15:36:39 +0100, Dongsu Park
wrote:
> Hi,
>
> 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.
Interesting
Hi,
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.
1. Test condition
- On host, ramdisk-backed block device (/dev/ram0)
- qemu-k
27 matches
Mail list logo
