qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Doubts about Kvm architecture


From: Eric Blake
Subject: Re: [Qemu-devel] Doubts about Kvm architecture
Date: Wed, 31 May 2017 16:44:43 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 05/31/2017 11:56 AM, Maurício Almeida wrote:

> The Traffic of Virtio was 956 MB/s while e1000 Emulated Driver was 192
> MB/s, both using Packet size of 1518 Bytes.

The quick answer - yes, that's the expected results, because paravirt is
SOOO much more direct than fully-emulated.  Everything done in the e1000
driver has to emulate what hardware would do, which tends to be a LOT of
register reads and writes to device memory, which in turn implies a LOT
of VMEXITs with corresponding overhead as you are paging between the
guest and host to handle the full sequence.  Meanwhile, the virtio
driver was designed from the ground up to be as efficient as possible,
by intentionally arranging memory layout and handshake protocols so that
there are as few memory-mapped register writes, and therefore as few
VMEXITs, as possible, for better speed and multithreading.

> 
> Why when it used e1000 Emulated Driver the traffic was to low and use only
> one Cpu all the time?

For any modern OS, the e1000 driver should only be used as a crutch to
get the system up and running until you can install and switch over to
the virtio drivers (we have it because it is a driver that is most
likely already installed on a guest OS out-of-the-box, while the virtio
driver might be an extra download or install after the initial guest
install has completed).  So optimizing the e1000 driver to run on
multiple vcpus is not our priority; rather, you should be optimizing
your guest provisioning setup to get switched over to the virtio drivers
as soon as possible.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]