On 03/04/17 12:42, Sunil Kovvuri wrote:
> On Mon, Apr 3, 2017 at 3:44 PM, Jean-Philippe Brucker
> <jean-philippe.brucker@xxxxxxx> wrote:
>> On 03/04/17 09:34, Sunil Kovvuri wrote:
>>>> +static size_t arm_smmu_atc_invalidate_domain(struct arm_smmu_domain *smmu_domain,
>>>> + unsigned long iova, size_t size)
>>>> +{
>>>> + unsigned long flags;
>>>> + struct arm_smmu_cmdq_ent cmd = {0};
>>>> + struct arm_smmu_group *smmu_group;
>>>> + struct arm_smmu_master_data *master;
>>>> + struct arm_smmu_device *smmu = smmu_domain->smmu;
>>>> + struct arm_smmu_cmdq_ent sync_cmd = {
>>>> + .opcode = CMDQ_OP_CMD_SYNC,
>>>> + };
>>>> +
>>>> + spin_lock_irqsave(&smmu_domain->groups_lock, flags);
>>>> +
>>>> + list_for_each_entry(smmu_group, &smmu_domain->groups, domain_head) {
>>>> + if (!smmu_group->ats_enabled)
>>>> + continue;
>>>
>>> If ATS is not supported, this seems to increase no of cycles spent in
>>> pgtbl_lock.
>>> Can we return from this API by checking 'ARM_SMMU_FEAT_ATS' in smmu->features ?
>>
>> Sure, I can add a check before taking the lock. Have you been able to
>> observe a significant difference in cycles between checking FEAT_ATS,
>> checking group->ats_enabled after taking the lock, and removing this
>> function call altogether?
>>
>> Thanks,
>> Jean-Philippe
>
> No, I haven't verified, was just making an observation.
Fair enough, I think avoiding the lock when ATS isn't in use makes sense.
Thanks,
Jean-Philippe
