From: Anthony Liguori <anthony@codemonkey.ws>
To: Ben-Ami Yassour <benami@il.ibm.com>
Cc: Avi Kivity <avi@qumranet.com>,
amit.shah@qumranet.com, kvm@vger.kernel.org,
Muli Ben-Yehuda <muli@il.ibm.com>,
weidong.han@intel.com
Subject: Re: PCI passthrough with VT-d - native performance
Date: Wed, 16 Jul 2008 10:23:08 -0500 [thread overview]
Message-ID: <487E125C.7020301@codemonkey.ws> (raw)
In-Reply-To: <1216221530.31546.274.camel@cluwyn.haifa.ibm.com>
Ben-Ami Yassour wrote:
> On Wed, 2008-07-16 at 17:36 +0300, Avi Kivity wrote:
>
>> Ben-Ami Yassour wrote:
>>
>>> In last few tests that we made with PCI-passthrough and VT-d using
>>> iperf, we were able to get the same throughput as on native OS with a 1G
>>> NIC
>>>
>> Excellent!
>>
>>
>>> (with higher CPU utilization).
>>>
>>>
>> How much higher?
>>
>
> Here are some numbers for running iperf -l 1M:
>
> e1000 NIC (behind a PCI bridge)
> Bandwidth (Mbit/sec) CPU utilization
> Native OS 771 18%
> Native OS with VT-d 760 18%
> KVM VT-d 390 95%
> KVM VT-d with direct mmio 770 84%
> KVM emulated 57 100%
>
What about virtio? Also, which emulated is this?
That CPU utilization is extremely high and somewhat illogical if native
w/vt-d has almost no CPU impact. Have you run oprofile yet or have any
insight into where CPU is being burnt?
What does kvm_stat look like? I wonder if there are a large number of
PIO exits. What does the interrupt count look like on native vs. KVM
with VT-d?
Regards,
Anthony Liguori
> Comment: its not clear to me why the native linux can not get closer to 1G for this NIC,
> (I verified that its not external network issues). But clearly we shouldn't hope to
> get more then the host does with a KVM guest (especially if the guest and host are the
> same OS as in this case...).
>
> e1000e NIC (onboard)
> Bandwidth (Mbit/sec) CPU utilization
> Native OS 915 18%
> Native OS with VT-d 915 18%
> KVM VT-d with direct mmio 914 98%
>
> Clearly we need to try and improve the CPU utilization, but I think that this is good enough
> for the first phase.
>
>
>>> The following patches are the PCI-passthrough patches that Amit sent
>>> (re-based on the last kvm tree), followed by a few improvements and the
>>> VT-d extension.
>>> I am also sending the userspace patches: the patch that Amit sent for
>>> PCI passthrough and the direct-mmio extension for userspace (note that
>>> without the direct mmio extension we get less then half the throughput).
>>>
>>>
>> Is mmio passthrough the reason for the performance improvement? If not,
>> what was the problem?
>>
>>
> Direct mmio was definitely a major improvement, without it we got half the throughput,
> as you can see above.
> In addition patch 4/8 improves the interrupt handling and removes unnecessary locks,
> and I assume that it also fixed performance issues (I did not investigate exactly in what way).
>
> Regards,
> Ben
>
>
>
next prev parent reply other threads:[~2008-07-16 15:23 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 13:16 PCI passthrough with VT-d - native performance Ben-Ami Yassour
2008-07-16 13:16 ` [PATCH 1/8] KVM: Introduce a callback routine for IOAPIC ack handling Ben-Ami Yassour
2008-07-16 13:16 ` [PATCH 2/8] KVM: Introduce a callback routine for PIC " Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 3/8] KVM: Handle device assignment to guests Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 4/8] KVM: PCIPT: fix interrupt handling Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 5/8] KVM: PCIPT: change order of device release Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 6/8] VT-d: changes to support KVM Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 7/8] KVM: PCIPT: VT-d support Ben-Ami Yassour
2008-07-16 13:17 ` [PATCH 8/8] KVM: PCIPT: VT-d: dont map mmio memory slots Ben-Ami Yassour
2008-07-16 13:21 ` PCI passthrough with VT-d - native performance Ben-Ami Yassour
2008-07-16 13:21 ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devices to guest Ben-Ami Yassour
2008-07-16 13:21 ` [PATCH 2/2] PCIPT: direct mmio Ben-Ami Yassour
2008-07-17 7:52 ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devices to guest Han, Weidong
2008-07-22 12:28 ` Ben-Ami Yassour
2008-07-22 12:44 ` [PATCH 1/2] KVM/userspace: Support for assigning PCI devicesto guest Han, Weidong
2008-07-16 15:06 ` [PATCH 5/8] KVM: PCIPT: change order of device release Avi Kivity
2008-07-16 15:06 ` [PATCH 4/8] KVM: PCIPT: fix interrupt handling Avi Kivity
2008-07-23 13:37 ` Amit Shah
2008-07-24 11:28 ` Ben-Ami Yassour
2008-07-24 13:31 ` Amit Shah
2008-07-24 14:24 ` Ben-Ami Yassour
2008-07-16 15:04 ` [PATCH 3/8] KVM: Handle device assignment to guests Avi Kivity
2008-07-17 2:09 ` Han, Weidong
2008-07-17 2:29 ` Yang, Sheng
2008-07-17 6:02 ` Avi Kivity
2008-07-17 8:23 ` Ben-Ami Yassour
2008-07-17 8:31 ` Avi Kivity
2008-07-17 18:01 ` Ben-Ami Yassour
2008-07-17 18:07 ` Avi Kivity
2008-07-17 9:34 ` Ben-Ami Yassour
2008-07-17 9:50 ` Avi Kivity
2008-07-17 17:40 ` Ben-Ami Yassour
2008-07-17 18:04 ` Avi Kivity
2008-07-16 14:36 ` PCI passthrough with VT-d - native performance Avi Kivity
2008-07-16 15:18 ` Ben-Ami Yassour
2008-07-16 15:22 ` Avi Kivity
2008-07-16 15:23 ` Anthony Liguori [this message]
2008-07-16 16:13 ` Ben-Ami Yassour
2008-07-16 16:57 ` Avi Kivity
2008-07-17 6:24 ` Ben-Ami Yassour
2008-07-17 3:20 ` Han, Weidong
-- strict thread matches above, loose matches on Subject: below --
2008-07-16 15:56 Ben-Ami Yassour
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=487E125C.7020301@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=amit.shah@qumranet.com \
--cc=avi@qumranet.com \
--cc=benami@il.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=muli@il.ibm.com \
--cc=weidong.han@intel.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.