On 03/04/17 12:42, Sunil Kovvuri wrote: > On Mon, Apr 3, 2017 at 3:44 PM, Jean-Philippe Brucker > <jean-philippe.bruc...@arm.com> 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 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu