From: john cooper <john.cooper@redhat.com>
To: Lucas Nussbaum <lucas@lucas-nussbaum.net>
Cc: john cooper <john.cooper@third-harmonic.com>,
kvm@vger.kernel.org, john.cooper@redhat.com
Subject: Re: bad virtio disk performance
Date: Mon, 27 Apr 2009 19:40:11 -0400 [thread overview]
Message-ID: <49F6425B.6010000@redhat.com> (raw)
In-Reply-To: <20090427182830.GA32574@xanadu.blop.info>
Lucas Nussbaum wrote:
> On 27/04/09 at 13:36 -0400, john cooper wrote:
>> Lucas Nussbaum wrote:
>
> non-virtio:
> kvm -drive file=/tmp/debian-amd64.img,if=scsi,cache=writethrough -net
> nic,macaddr=00:16:3e:5a:28:1,model=e1000 -net tap -nographic -kernel
> /boot/vmlinuz-2.6.29 -initrd /boot/initrd.img-2.6.29 -append
> root=/dev/sda1 ro console=tty0 console=ttyS0,9600,8n1
>
> virtio:
> kvm -drive file=/tmp/debian-amd64.img,if=virtio,cache=writethrough -net
> nic,macaddr=00:16:3e:5a:28:1,model=e1000 -net tap -nographic -kernel
> /boot/vmlinuz-2.6.29 -initrd /boot/initrd.img-2.6.29 -append
> root=/dev/vda1 ro console=tty0 console=ttyS0,9600,8n1
>
One suggestion would be to use a separate drive
for the virtio vs. non-virtio comparison to avoid
a Heisenberg effect.
>
> So, apparently, with virtio, there's a lot more data being written to
> disk. The underlying filesystem is ext3, and is monted as /tmp. It only
> contains the VM image file. Another difference is that, with virtio, the
> data was shared equally over all 4 CPUs, with without virt-io, CPU0 and
> CPU1 did all the work.
> In the virtio log, I also see a (null) process doing a lot of writes.
Can't say what is causing that -- only took a look
at the short logs. However the isolation suggested
above may help factor that out if you need to
pursue this path.
>
> I uploaded the logs to http://blop.info/bazaar/virtio/, if you want to
> take a look.
In the virtio case i/o is being issued from multiple
threads. You could be hitting the cfq close-cooperator
bug we saw as late as 2.6.28.
A quick test to rule this in/out would be to change
the block scheduler to other than cfq for the host
device where the backing image resides -- in your
case the host device containing /tmp/debian-amd64.img.
Eg for /dev/sda1:
# cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
# echo deadline > /sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
And re-run your test to see if this brings
virtio vs. non-virtio closer to the expected
performance.
-john
--
john.cooper@redhat.com
next prev parent reply other threads:[~2009-04-27 23:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 15:12 bad virtio disk performance Lucas Nussbaum
2009-04-27 17:36 ` john cooper
2009-04-27 18:28 ` Lucas Nussbaum
2009-04-27 23:40 ` john cooper [this message]
2009-04-28 10:56 ` Lucas Nussbaum
2009-04-28 11:48 ` Lucas Nussbaum
2009-04-28 11:55 ` Avi Kivity
2009-04-28 14:35 ` Lucas Nussbaum
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=49F6425B.6010000@redhat.com \
--to=john.cooper@redhat.com \
--cc=john.cooper@third-harmonic.com \
--cc=kvm@vger.kernel.org \
--cc=lucas@lucas-nussbaum.net \
/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.