From: "Michael S. Tsirkin" <mst@redhat.com>
To: lidong chen <chen.lidong.kernel@gmail.com>
Cc: "Yang, Sheng" <sheng.yang@intel.com>, Avi Kivity <avi@redhat.com>,
Gleb Natapov <gleb@redhat.com>,
"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Performance test result between virtio_pci MSI-X disable and enable
Date: Wed, 1 Dec 2010 16:03:58 +0200 [thread overview]
Message-ID: <20101201140357.GD12912@redhat.com> (raw)
In-Reply-To: <AANLkTikMRE=G3q3gJmwdrrSpG6FgP62zBobGKy7OhtUp@mail.gmail.com>
On Wed, Dec 01, 2010 at 04:41:38PM +0800, lidong chen wrote:
> I used sr-iov, give each vm 2 vf.
> after apply the patch, and i found performence is the same.
>
> the reason is in function msix_mmio_write, mostly addr is not in mmio range.
>
> static int msix_mmio_write(struct kvm_io_device *this, gpa_t addr, int len,
> const void *val)
> {
> struct kvm_assigned_dev_kernel *adev =
> container_of(this, struct kvm_assigned_dev_kernel,
> msix_mmio_dev);
> int idx, r = 0;
> unsigned long new_val = *(unsigned long *)val;
>
> mutex_lock(&adev->kvm->lock);
> if (!msix_mmio_in_range(adev, addr, len)) {
> // return here.
> r = -EOPNOTSUPP;
> goto out;
> }
>
> i printk the value:
> addr start end len
> F004C00C F0044000 F0044030 4
>
> 00:06.0 Ethernet controller: Intel Corporation Unknown device 10ed (rev 01)
> Subsystem: Intel Corporation Unknown device 000c
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Region 0: Memory at f0040000 (32-bit, non-prefetchable) [size=16K]
> Region 3: Memory at f0044000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [40] MSI-X: Enable+ Mask- TabSize=3
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00002000
>
> 00:07.0 Ethernet controller: Intel Corporation Unknown device 10ed (rev 01)
> Subsystem: Intel Corporation Unknown device 000c
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Region 0: Memory at f0048000 (32-bit, non-prefetchable) [size=16K]
> Region 3: Memory at f004c000 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [40] MSI-X: Enable+ Mask- TabSize=3
> Vector table: BAR=3 offset=00000000
> PBA: BAR=3 offset=00002000
>
>
>
> +static bool msix_mmio_in_range(struct kvm_assigned_dev_kernel *adev,
> + gpa_t addr, int len)
> +{
> + gpa_t start, end;
> +
> + BUG_ON(adev->msix_mmio_base == 0);
> + start = adev->msix_mmio_base;
> + end = adev->msix_mmio_base + PCI_MSIX_ENTRY_SIZE *
> + adev->msix_max_entries_nr;
> + if (addr >= start && addr + len <= end)
> + return true;
> +
> + return false;
> +}
Hmm, this check looks wrong to me: there's no guarantee
that guest uses the first N entries in the table.
E.g. it could use a single entry, but only the last one.
>
>
> 2010/11/30 Yang, Sheng <sheng.yang@intel.com>:
> > On Tuesday 30 November 2010 17:10:11 lidong chen wrote:
> >> sr-iov also meet this problem, MSIX mask waste a lot of cpu resource.
> >>
> >> I test kvm with sriov, which the vf driver could not disable msix.
> >> so the host os waste a lot of cpu. cpu rate of host os is 90%.
> >>
> >> then I test xen with sriov, there ara also a lot of vm exits caused by
> >> MSIX mask.
> >> but the cpu rate of xen and domain0 is less than kvm. cpu rate of xen
> >> and domain0 is 60%.
> >>
> >> without sr-iov, the cpu rate of xen and domain0 is higher than kvm.
> >>
> >> so i think the problem is kvm waste more cpu resource to deal with MSIX
> >> mask. and we can see how xen deal with MSIX mask.
> >>
> >> if this problem sloved, maybe with MSIX enabled, the performace is better.
> >
> > Please refer to my posted patches for this issue.
> >
> > http://www.spinics.net/lists/kvm/msg44992.html
> >
> > --
> > regards
> > Yang, Sheng
> >
> >>
> >> 2010/11/23 Avi Kivity <avi@redhat.com>:
> >> > On 11/23/2010 09:27 AM, lidong chen wrote:
> >> >> can you tell me something about this problem.
> >> >> thanks.
> >> >
> >> > Which problem?
> >> >
> >> > --
> >> > I have a truly marvellous patch that fixes the bug which this
> >> > signature is too narrow to contain.
> >
next prev parent reply other threads:[~2010-12-01 14:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-23 2:53 Performance test result between virtio_pci MSI-X disable and enable lidong chen
2010-11-23 6:20 ` Avi Kivity
2010-11-23 6:42 ` Gleb Natapov
2010-11-23 7:27 ` lidong chen
2010-11-23 7:39 ` Avi Kivity
2010-11-30 9:10 ` lidong chen
2010-11-30 9:24 ` Yang, Sheng
2010-12-01 8:41 ` lidong chen
2010-12-01 8:49 ` Yang, Sheng
2010-12-01 8:54 ` lidong chen
2010-12-01 9:02 ` Yang, Sheng
2010-12-01 9:29 ` lidong chen
2010-12-01 9:37 ` Yang, Sheng
2010-12-01 9:34 ` Yang, Sheng
2010-12-01 8:56 ` Yang, Sheng
2010-12-01 14:03 ` Michael S. Tsirkin [this message]
2010-12-02 1:13 ` Yang, Sheng
2010-12-02 9:49 ` Michael S. Tsirkin
2010-12-02 11:52 ` Sheng Yang
2010-12-02 12:23 ` Michael S. Tsirkin
2010-12-02 14:01 ` lidong chen
2010-12-22 13:52 ` Michael S. Tsirkin
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=20101201140357.GD12912@redhat.com \
--to=mst@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=chen.lidong.kernel@gmail.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=sheng.yang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox