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. Thanks, Sunil.