On 2019/8/23 16:37, Will Deacon wrote:
> On Fri, Aug 23, 2019 at 04:06:52PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2019/8/23 15:50, Will Deacon wrote:
>>> On Fri, Aug 23, 2019 at 10:45:49AM +0800, Zhen Lei wrote:
>>>> v2 --> v3:
>>>> As Will Deacon's suggestion, I changed the lock type of
>>>> arm_smmu_domain.devices_lock from spinlock_t to rwlock_t, and I saw that
>>>> the
>>>> performance is all right. And further use nr_ats_masters to quickly check
>>>> have
>>>> no obvious effect, so I drop it.
>>>
>>> :/
>>>
>>> I already sent two versions of a series fixing this without any locking at
>>> all on the ->unmap() path, and you were on cc. I've also queued that stuff
>>> up.
>>>
>>> Did you not receive my patches?
>> Sorry, my message filter setting is a bit wrong, must contains
>> "linux-ker...@vger.kernel.org", I have corrected it.
>
> Ha, sounds like the opposite of my email filter ;)
>
>>> v1:
>>> https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038306.html
>>> v2:
>>> https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038374.html
>> OK, I will test it when it's my turn to use the board.
>
> Thanks, although I plan to send it to Joerg today so any changes will need
> to go on top. Does your testing involve ATS, or just non-ATS devices? I've
I also currently only have non-ATS devices.
> tested the latter locally, although I haven't looked at the performance
> since most of the patches are trying to fix the enable/disable ordering.
>
> Thanks,
>
> Will
>
> .
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
