linux-kernel - Re: [RFC PATCH 0/3] vfio/type1: Reduce vfio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200219135247.42d18bb2@w520.home>
Date:   Wed, 19 Feb 2020 13:52:47 -0700
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Yan Zhao <yan.y.zhao@...el.com>
Cc:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] vfio/type1: Reduce vfio_iommu.lock contention

On Wed, 19 Feb 2020 04:04:17 -0500
Yan Zhao <yan.y.zhao@...el.com> wrote:

> On Fri, Jan 17, 2020 at 09:10:51AM +0800, Yan Zhao wrote:
> > Thank you, Alex!
> > I'll try it and let you know the result soon. :)
> > 
> > On Fri, Jan 17, 2020 at 02:17:49AM +0800, Alex Williamson wrote:  
> > > Hi Yan,
> > > 
> > > I wonder if this might reduce the lock contention you're seeing in the
> > > vfio_dma_rw series.  These are only compile tested on my end, so I hope
> > > they're not too broken to test.  Thanks,
> > > 
> > > Alex
> > > 
> > > ---
> > > 
> > > Alex Williamson (3):
> > >       vfio/type1: Convert vfio_iommu.lock from mutex to rwsem
> > >       vfio/type1: Replace obvious read lock instances
> > >       vfio/type1: Introduce pfn_list mutex
> > > 
> > > 
> > >  drivers/vfio/vfio_iommu_type1.c |   67 ++++++++++++++++++++++++---------------
> > >  1 file changed, 41 insertions(+), 26 deletions(-)
> > >  
> 
> hi Alex
> I have finished testing of this series.
> It's quite stable and passed our MTBF testing :)
> 
> However, after comparing the performance data obtained from several
> benchmarks in guests (see below),
> it seems that this series does not bring in obvious benefit.
> (at least to cases we have tested, and though I cannot fully explain it yet).
> So, do you think it's good for me not to include this series into my next
> version of "use vfio_dma_rw to read/write IOVAs from CPU side"?

Yes, I would not include it in your series.  No reason to bloat your
series for a feature that doesn't clearly show an improvement.  Thanks
for the additional testing, we can revive them if this lock ever
resurfaces.  I'm was actually more hopeful that holding an external
group reference might provide a better performance improvement, the
lookup on every vfio_dma_rw is not very efficient.  Thanks,

Alex