Re: [RFC PATCH v2 00/19] Try to reduce lock contention on the SMMUv3 command queue

[John Garry <john.garry@huawei.com>]

On 24/07/2019 15:48, Will Deacon wrote:
> On Wed, Jul 24, 2019 at 03:25:07PM +0100, John Garry wrote:
>> On 24/07/2019 13:20, Will Deacon wrote:
>>> On Wed, Jul 24, 2019 at 10:58:26AM +0100, John Garry wrote:
>>>> On 11/07/2019 18:19, Will Deacon wrote:
>>>>> This is a significant rework of the RFC I previously posted here:
>>>>>
>>>>>   https://lkml.kernel.org/r/20190611134603.4253-1-will.deacon@arm.com
>>>>>
>>>>> But this time, it looks like it might actually be worthwhile according
>>>>> to my perf profiles, where __iommu_unmap() falls a long way down the
>>>>> profile for a multi-threaded netperf run. I'm still relying on others to
>>>>> confirm this is useful, however.
>>>>>
>>>>> Some of the changes since last time are:
>>>>>
>>>>>   * Support for constructing and submitting a list of commands in the
>>>>>     driver
>>>>>
>>>>>   * Numerous changes to the IOMMU and io-pgtable APIs so that we can
>>>>>     submit commands in batches
>>>>>
>>>>>   * Removal of cmpxchg() from cmdq_shared_lock() fast-path
>>>>>
>>>>>   * Code restructuring and cleanups
>>>>>
>>>>> This current applies against my iommu/devel branch that Joerg has pulled
>>>>> for 5.3. If you want to test it out, I've put everything here:
>>>>>
>>>>>   https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=iommu/cmdq
>>>>>
>>>>> Feedback welcome. I appreciate that we're in the merge window, but I
>>>>> wanted to get this on the list for people to look at as an RFC.
>>>>>
>>>>
>>>> I tested storage performance on this series, which I think is a better
>>>> scenario to test than network performance, that being generally limited by
>>>> the network link speed.
>>>
>>> Interesting, thanks for sharing. Do you also see a similar drop in CPU time
>>> to the one reported by Ganapat?
>>
>> Not really, CPU load reported by fio is mostly the same.
>
> That's a pity. Maybe the cmdq isn't actually getting hit very heavily by
> fio.
>
>>>> Baseline performance (will/iommu/devel, commit 9e6ea59f3)
>>>> 8x SAS disks D05	839K IOPS
>>>> 1x NVMe D05		454K IOPS
>>>> 1x NVMe D06		442k IOPS
>>>>
>>>> Patchset performance (will/iommu/cmdq)
>>>> 8x SAS disk D05		835K IOPS
>>>> 1x NVMe D05		472K IOPS
>>>> 1x NVMe D06		459k IOPS
>>>>
>>>> So we see a bit of an NVMe boost, but about the same for 8x disks. No iommu
>>>> performance is about 918K IOPs for 8x disks, so it is not limited by the
>>>> medium.
>>>
>>> It would be nice to know if this performance gap is because of Linux, or
>>> simply because of the translation overhead in the SMMU hardware. Are you
>>> able to get a perf profile to see where we're spending time?
>>
>> I'll look to do that, but I'd really expect it to be down to the time linux
>> spends on the DMA map and unmaps.
>
> Right, and it would be good to see how much of that is in SMMUv3-specific
> code. Another interesting thing to try would be reducing the depth of the
> io-pgtable. We currently key that off VA_BITS which may be much larger
> than you need (by virtue of being a compile-time value).
>

The perf call-graph before and after is below. Interesting to see how 
long the mapping takes. So changing the io-pgtable depth may help here.

The unmapping speed improves - I don't know why it doesn't help the 8x 
disk scenario throughput, which these profiles are based on.

JFYI, our HW guys are quite concerned with the SMMU programming 
interface, specifically having a single submission queue which requires 
locking or some sort of synchronization. Obviously it's not a single 
culprit for consuming time.

before map
  |--3.02%--__iommu_map_sg_attrs
      |
      --2.99%--iommu_dma_map_sg
             |
             --2.71%--iommu_map_sg
                |
                --2.58%--iommu_map
                    |
                   --2.50%--arm_smmu_map
                          |
                          --2.48%--arm_lpae_map
                               |
                               --0.66%--__arm_lpae_map
                                     |
                                     --0.50%--__arm_lpae_map


after map
--3.25%--__iommu_map_sg_attrs
     |
     --3.20%--iommu_dma_map_sg
          |
          --2.77%--iommu_map_sg
               |
               --2.62%--iommu_map
                    |
                     --2.53%--arm_smmu_map
                            |
                            --2.49%--arm_lpae_map
                                   |
                                   --0.72%--__arm_lpae_map
                                         |
                                         --0.56%--__arm_lpae_map

before unmap
--5.64%--__iommu_unmap_sg_attrs
   |
   --5.63%--iommu_dma_unmap_sg
     |
      --5.53%--__iommu_dma_unmap
        |
        --4.97%--iommu_unmap_fast
          |
          --4.94%--__iommu_unmap
            |
            --4.91%--arm_smmu_unmap
               |
                --4.83%--arm_lpae_unmap
                   |
                   --4.80%--__arm_lpae_unmap
                     |
                     --4.62%--__arm_lpae_unmap
                        |
                        --4.50%--__arm_lpae_unmap
                           |
                           --4.33%--__arm_lpae_unmap
                             |
                              --4.13%--arm_smmu_tlb_inv_range_nosync
                                |
                                 --3.97%--arm_smmu_cmdq_issue_cmd
                                   |
                                    --3.74%--_raw_spin_unlock_irqrestore

after unmap
--2.75%--__iommu_unmap_sg_attrs
     |
     --2.74%--iommu_dma_unmap_sg
        |
        --2.59%--__iommu_dma_unmap
              |
              |--1.82%--arm_smmu_iotlb_sync
              |       |
              |        --1.78%--arm_smmu_tlb_inv_range
              |              |
              |              --1.75%--arm_smmu_cmdq_issue_cmdlist
              |
              --0.65%--iommu_unmap_fast
                  |
                   --0.64%--__iommu_unmap
                        |
                        --0.62%--arm_smmu_unmap
                            |
                            --0.55%--arm_lpae_unmap
                                  |
                                  --0.54%--__arm_lpae_unmap


I tried to capture a record for direct DMA, but dma_direct_map_sg et al 
wasn't even showing in graph. That's the target...

John

> Will
>
> .
>


_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu