[Patch v2 0/3] iommu: reduce spinlock contention on fast path

This patchset contains three small optimizations for the global spinlock contention in IOVA cache. Our memcache perf test shows this reduced its p999 latency down by 45% on AMD when IOMMU is enabled. Cong Wang (3): iommu: match the original algorithm iommu: optimize iova_magazine_free_pfns()

[Patch v2 3/3] iommu: avoid taking iova_rbtree_lock twice

Both find_iova() and __free_iova() take iova_rbtree_lock, there is no reason to take and release it twice inside free_iova(). Fold them into the critical section by calling the unlock versions instead. Cc: Joerg Roedel Signed-off-by: Cong Wang --- drivers/iommu/iova.c | 8 ++-- 1 file chan

[Patch v2 2/3] iommu: optimize iova_magazine_free_pfns()

If the maganize is empty, iova_magazine_free_pfns() should be a nop, however it misses the case of mag->size==0. So we should just call iova_magazine_empty(). This should reduce the contention on iovad->iova_rbtree_lock a little bit. Cc: Joerg Roedel Signed-off-by: Cong Wang --- drivers/iommu/

[Patch v2 1/3] iommu: match the original algorithm

The IOVA cache algorithm implemented in IOMMU code does not exactly match the original algorithm described in the paper. Particularly, it doesn't need to free the loaded empty magazine when trying to put it back to global depot. To make it work, we have to pre-allocate magazines in the depot and o

Re: [GIT PULL] dma-mapping updates for 5.5

The pull request you sent on Thu, 28 Nov 2019 17:49:04 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/81b6b96475ac7a4ebfceae9f16fb3758327adbfe Thank you! -- Deet-doot-dot, I am a bot. ht

Re: [PATCH 1/3] iommu: match the original algorithm

On Wed, Nov 27, 2019 at 10:01 AM John Garry wrote: > > On 21/11/2019 00:13, Cong Wang wrote: > > The IOVA cache algorithm implemented in IOMMU code does not > > exactly match the original algorithm described in the paper. > > > > Particularly, it doesn't need to free the loaded empty magazine > >

[GIT PULL] dma-mapping updates for 5.5

Hi Linus, please pull the dma-mapping updates for Linux 5.5. Before the last commit I had to pull in a branch from the arm64 tree (which has already been merged in master) as we'd otherwise generate some horribly to resolve merge conflicts as both changed the area in different ways. Except for t

Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

On Thu, Nov 28, 2019 at 08:02:16AM +, Thomas Hellstrom wrote: > > We have a hard time handling that in generic code. Do we have any > > good use case for SWIOTLB_FORCE not that we have force_dma_unencrypted? > > I'd love to be able to get rid of it.. > > > IIRC the justification for it is debu

Re: [PATCH 2/2] iommu: dma: Use of_iommu_get_resv_regions()

On Wed, Nov 27, 2019 at 05:09:41PM +, Robin Murphy wrote: > On 27/11/2019 2:16 pm, Thierry Reding wrote: > [...] > > Nevermind that, I figured out that I was missingthe initialization of > > some of the S2CR variables. I've got something that I think is working > > now, though I don't know yet

Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

On 11/28/19 8:51 AM, h...@lst.de wrote: > On Wed, Nov 27, 2019 at 06:22:57PM +, Thomas Hellstrom wrote: >>> bool dma_addressing_limited(struct device *dev) >>> { >>> + if (force_dma_unencrypted(dev)) >>> + return true; >>> return min_not_zero(dma_get_mask(dev), dev->bus_dma_li