Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

2019-09-17 Thread Leizhen (ThunderTown)



On 2019/8/23 16:06, 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.
> 
>>
>> 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.

The test result shows good to me, without these patches, it's about 22xx-23xx

Jobs: 24 (f=24): [] [0.6% done] [11160M/0K /s] [2725K/0 
Jobs: 24 (f=24): [] [0.6% done] [11165M/0K /s] [2726K/0 
Jobs: 24 (f=24): [] [0.6% done] [11220M/0K /s] [2739K/0 
Jobs: 24 (f=24): [] [0.6% done] [11189M/0K /s] [2732K/0 
Jobs: 24 (f=24): [] [0.6% done] [11082M/0K /s] [2705K/0 
Jobs: 24 (f=24): [] [0.6% done] [11003M/0K /s] [2686K/0 
Jobs: 24 (f=24): [] [0.6% done] [11412M/0K /s] [2786K/0 
Jobs: 24 (f=24): [] [0.6% done] [11415M/0K /s] [2787K/0 
Jobs: 24 (f=24): [] [0.6% done] [11214M/0K /s] [2738K/0 
Jobs: 24 (f=24): [] [0.6% done] [11054M/0K /s] [2699K/0 
Jobs: 24 (f=24): [] [0.6% done] [10733M/0K /s] [2620K/0 
Jobs: 24 (f=24): [] [0.6% done] [10772M/0K /s] [2630K/0 
Jobs: 24 (f=24): [] [0.7% done] [10772M/0K /s] [2630K/0 

> 
>>
>> Queued: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/smmu-v3
>>
>> Will
>>
>> .
>>
> 
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
> 
> 

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


Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

2019-08-23 Thread Leizhen (ThunderTown)



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


Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

2019-08-23 Thread Will Deacon
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
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


Re: [PATCH v3 0/2] improve the concurrency of arm_smmu_atc_inv_domain()

2019-08-23 Thread Will Deacon
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?

v1: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038306.html
v2: https://lists.linuxfoundation.org/pipermail/iommu/2019-August/038374.html

Queued: 
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/smmu-v3

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