All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugenio Perez Martin <eperezma@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Aleksandar Rikalo" <aleksandar.rikalo@syrmia.com>,
	"Yan Zhao" <yan.y.zhao@intel.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	qemu-level <qemu-devel@nongnu.org>,
	"Eric Auger" <eric.auger@redhat.com>,
	qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	"Avi Kivity" <avi@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"David Gibson" <david@gibson.dropbear.id.au>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [RFC v8 4/5] intel_iommu: Do not notify regular iotlb to device-iotlb notifiers
Date: Thu, 3 Sep 2020 08:07:19 +0200	[thread overview]
Message-ID: <CAJaqyWeNkL3Qc11NZcWgFm5vMfhAREf7m0u0zPi2vpDLwkm9zw@mail.gmail.com> (raw)
In-Reply-To: <20200901210424.GF3053@xz-x1>

On Tue, Sep 1, 2020 at 11:06 PM Peter Xu <peterx@redhat.com> wrote:
>
> On Tue, Sep 01, 2020 at 04:26:07PM +0200, Eugenio Pérez wrote:
> > This improves performance in case of netperf with vhost-net:
> > * TCP_STREAM: From 1923.6Mbit/s to 2175.13Mbit/s (13%)
> > * TCP_RR: From 8464.73 trans/s to 8932.703333 trans/s (5.5%)
> > * UDP_RR: From 8562.08 trans/s to 9005.62/s (5.1%)
> > * UDP_STREAM: No change observed (insignificant 0.1% improvement)
>
> Just to confirm: are these numbers about applying this patch before/after, or
> applying the whole series before/after?
>
> Asked since we actually optimized two parts:
>
> Firstly we avoid sending two invalidations for vhost.  That's done by the
> previous patch, afaict.
>
> Secondly, this patch avoids the page walk for vhost since not needed.
>
> Am I right?
>

Right! The numbers are comparing v5.1.0 tag to this commit. Avoiding
sending invalidations for vhost did improve performance but in a very
small number, I thought it would improve more.

It also depends a lot on using rhel8 (better numbers, less but
appreciable improvements) or rhel7 guest (worse performance compared
to rhel8 but patches provide more improvements).


> >
> > Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
> > ---
> >  hw/i386/intel_iommu.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > index cdddb089e7..fe82391b73 100644
> > --- a/hw/i386/intel_iommu.c
> > +++ b/hw/i386/intel_iommu.c
> > @@ -1964,6 +1964,12 @@ static void vtd_iotlb_domain_invalidate(IntelIOMMUState *s, uint16_t domain_id)
> >      vtd_iommu_unlock(s);
> >
> >      QLIST_FOREACH(vtd_as, &s->vtd_as_with_notifiers, next) {
> > +        if (vtd_as->iommu.iommu_notify_flags & IOMMU_NOTIFIER_DEVIOTLB) {
> > +            /* If IOMMU memory region is DEVICE IOTLB type, it does not make
> > +             * sense to send regular IOMMU notifications. */
> > +            continue;
> > +        }
> > +
>
> We want to avoid vtd_sync_shadow_page_table() for vhost, however IMHO a better
> expression would be:
>
>     if (!(vtd_as->iommu.iommu_notify_flags &
>         (IOMMU_NOTIFIER_MAP | IOMMU_NOTIFIER_UNMAP))) {
>         continue;
>     }
>
> The thing is we can't avoid the page sync if e.g. we're registered with
> MAP|UNMAP|DEVIOTLB.  The important thing here, imho, is MAP|UNMAP because these
> two messages are used for shadow page synchronizations, so we can skip that if
> neither of the message is registered.
>
> Besides, we can add this at the entry of vtd_sync_shadow_page_table() so that
> all callers of vtd_sync_shadow_page_table() can benefit.
>

Agree on both. Testing the new changes.

Thanks!



> >          if (!vtd_dev_to_context_entry(s, pci_bus_num(vtd_as->bus),
> >                                        vtd_as->devfn, &ce) &&
> >              domain_id == vtd_get_domain_id(s, &ce)) {
> > --
> > 2.18.1
> >
>
> --
> Peter Xu
>
>



  reply	other threads:[~2020-09-03  6:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01 14:26 [RFC v8 0/5] memory: Delete assertion in memory_region_unregister_iommu_notifier Eugenio Pérez
2020-09-01 14:26 ` [RFC v8 1/5] memory: Rename memory_region_notify_one to memory_region_notify_iommu_one Eugenio Pérez
2020-09-01 20:44   ` Peter Xu
2020-09-02  0:37   ` David Gibson
2020-09-02  7:42   ` Juan Quintela
2020-09-02  9:04   ` Auger Eric
2020-09-01 14:26 ` [RFC v8 2/5] memory: Add IOMMUTLBEvent Eugenio Pérez
2020-09-01 20:54   ` Peter Xu
2020-09-02  8:14     ` Eugenio Perez Martin
2020-09-02  7:54   ` Juan Quintela
2020-09-02  8:39     ` Eugenio Perez Martin
2020-09-02 10:17   ` Auger Eric
2020-09-02 13:18     ` Eugenio Perez Martin
2020-09-02 13:39       ` Auger Eric
2020-09-02 13:58         ` Eugenio Perez Martin
2020-09-02 14:02           ` Eugenio Perez Martin
2020-09-01 14:26 ` [RFC v8 3/5] memory: Add IOMMU_DEVIOTLB_UNMAP IOMMUTLBNotificationType Eugenio Pérez
2020-09-01 20:56   ` Peter Xu
2020-09-02  7:55   ` Juan Quintela
2020-09-02 10:31   ` Auger Eric
2020-09-03 10:13     ` Eugenio Perez Martin
2020-09-03 11:06       ` Auger Eric
2020-09-03 12:21         ` Eugenio Perez Martin
2020-09-01 14:26 ` [RFC v8 4/5] intel_iommu: Do not notify regular iotlb to device-iotlb notifiers Eugenio Pérez
2020-09-01 21:04   ` Peter Xu
2020-09-03  6:07     ` Eugenio Perez Martin [this message]
2020-09-01 14:26 ` [RFC v8 5/5] memory: Skip bad range assertion if notifier is DEVIOTLB type Eugenio Pérez
2020-09-01 21:05   ` Peter Xu
2020-09-02  7:59   ` Juan Quintela
2020-09-02 14:24   ` Auger Eric
2020-09-02 23:57     ` David Gibson
2020-09-03 17:05       ` Eugenio Perez Martin
2020-09-01 21:13 ` [RFC v8 0/5] memory: Delete assertion in memory_region_unregister_iommu_notifier Peter Xu
2020-09-02  8:01   ` Eugenio Perez Martin

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=CAJaqyWeNkL3Qc11NZcWgFm5vMfhAREf7m0u0zPi2vpDLwkm9zw@mail.gmail.com \
    --to=eperezma@redhat.com \
    --cc=aleksandar.rikalo@syrmia.com \
    --cc=avi@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=hpoussin@reactos.org \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    --cc=yan.y.zhao@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.