| Message ID | 20190815054439.30652-3-thunder.leizhen@huawei.com |
|---|---|
| State | New |
| Headers | show |
| Series | add nr_ats_masters for quickly check | expand |
On Thu, Aug 15, 2019 at 01:44:39PM +0800, Zhen Lei wrote: > When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a > smmu domain does not contain any ats master, the operations of > arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain() > are always executed. This will impact performance, especially in > multi-core and stress scenarios. For my FIO test scenario, about 8% > performance reduced. > > In fact, we can use a struct member to record how many ats masters that > the smmu contains. And check that without traverse the list and check all > masters one by one in the lock protection. > > Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS") > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > drivers/iommu/arm-smmu-v3.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > index 29056d9bb12aa01..154334d3310c9b8 100644 > --- a/drivers/iommu/arm-smmu-v3.c > +++ b/drivers/iommu/arm-smmu-v3.c > @@ -631,6 +631,7 @@ struct arm_smmu_domain { > > struct io_pgtable_ops *pgtbl_ops; > bool non_strict; > + int nr_ats_masters; > > enum arm_smmu_domain_stage stage; > union { > @@ -1531,7 +1532,16 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, > struct arm_smmu_cmdq_ent cmd; > struct arm_smmu_master *master; > > - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS)) > + /* > + * The protectiom of spinlock(&iommu_domain->devices_lock) is omitted. > + * Because for a given master, its map/unmap operations should only be > + * happened after it has been attached and before it has been detached. > + * So that, if at least one master need to be atc invalidated, the > + * value of smmu_domain->nr_ats_masters can not be zero. > + * > + * This can alleviate performance loss in multi-core scenarios. > + */ I find this reasoning pretty dubious, since I think you're assuming that an endpoint cannot issue speculative ATS translation requests once its ATS capability is enabled. That said, I think it also means we should enable ATS in the STE *before* enabling it in the endpoint -- the current logic looks like it's the wrong way round to me (including in detach()). Anyway, these speculative translations could race with a concurrent unmap() call and end up with the ATC containing translations for unmapped pages, which I think we should try to avoid. Did the RCU approach not work out? You could use an rwlock instead as a temporary bodge if the performance doesn't hurt too much. Alternatively... maybe we could change the attach flow to do something like: enable_ats_in_ste(master); enable_ats_at_pcie_endpoint(master); spin_lock(devices_lock) add_to_device_list(master); nr_ats_masters++; spin_unlock(devices_lock); invalidate_atc(master); in which case, the concurrent unmapper will be doing something like: issue_tlbi(); smp_mb(); if (READ_ONCE(nr_ats_masters)) { ... } and I *think* that means that either the unmapper will see the nr_ats_masters update and perform the invalidation, or they'll miss the update but the attach will invalidate the ATC /after/ the TLBI in the command queue. Also, John's idea of converting this stuff over to my command batching mechanism should help a lot if we can defer this to sync time using the gather structure. Maybe an rwlock would be alright for that. Dunno. Will
On 2019/8/15 23:23, Will Deacon wrote: > On Thu, Aug 15, 2019 at 01:44:39PM +0800, Zhen Lei wrote: >> When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a >> smmu domain does not contain any ats master, the operations of >> arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain() >> are always executed. This will impact performance, especially in >> multi-core and stress scenarios. For my FIO test scenario, about 8% >> performance reduced. >> >> In fact, we can use a struct member to record how many ats masters that >> the smmu contains. And check that without traverse the list and check all >> masters one by one in the lock protection. >> >> Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS") >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >> --- >> drivers/iommu/arm-smmu-v3.c | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c >> index 29056d9bb12aa01..154334d3310c9b8 100644 >> --- a/drivers/iommu/arm-smmu-v3.c >> +++ b/drivers/iommu/arm-smmu-v3.c >> @@ -631,6 +631,7 @@ struct arm_smmu_domain { >> >> struct io_pgtable_ops *pgtbl_ops; >> bool non_strict; >> + int nr_ats_masters; >> >> enum arm_smmu_domain_stage stage; >> union { >> @@ -1531,7 +1532,16 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, >> struct arm_smmu_cmdq_ent cmd; >> struct arm_smmu_master *master; >> >> - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS)) >> + /* >> + * The protectiom of spinlock(&iommu_domain->devices_lock) is omitted. >> + * Because for a given master, its map/unmap operations should only be >> + * happened after it has been attached and before it has been detached. >> + * So that, if at least one master need to be atc invalidated, the >> + * value of smmu_domain->nr_ats_masters can not be zero. >> + * >> + * This can alleviate performance loss in multi-core scenarios. >> + */ > > I find this reasoning pretty dubious, since I think you're assuming that > an endpoint cannot issue speculative ATS translation requests once its > ATS capability is enabled. That said, I think it also means we should enable > ATS in the STE *before* enabling it in the endpoint -- the current logic > looks like it's the wrong way round to me (including in detach()). > > Anyway, these speculative translations could race with a concurrent unmap() > call and end up with the ATC containing translations for unmapped pages, > which I think we should try to avoid. > > Did the RCU approach not work out? You could use an rwlock instead as a > temporary bodge if the performance doesn't hurt too much. OK, I will try rwlock first, this does not change the original code logic. > > Alternatively... maybe we could change the attach flow to do something > like: > > enable_ats_in_ste(master); > enable_ats_at_pcie_endpoint(master); > spin_lock(devices_lock) > add_to_device_list(master); > nr_ats_masters++; > spin_unlock(devices_lock); > invalidate_atc(master); > > in which case, the concurrent unmapper will be doing something like: > > issue_tlbi(); > smp_mb(); > if (READ_ONCE(nr_ats_masters)) { > ... > } > > and I *think* that means that either the unmapper will see the > nr_ats_masters update and perform the invalidation, or they'll miss > the update but the attach will invalidate the ATC /after/ the TLBI > in the command queue. > > Also, John's idea of converting this stuff over to my command batching > mechanism should help a lot if we can defer this to sync time using the > gather structure. Maybe an rwlock would be alright for that. Dunno. > > Will > > . >
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index 29056d9bb12aa01..154334d3310c9b8 100644 --- a/drivers/iommu/arm-smmu-v3.c +++ b/drivers/iommu/arm-smmu-v3.c @@ -631,6 +631,7 @@ struct arm_smmu_domain { struct io_pgtable_ops *pgtbl_ops; bool non_strict; + int nr_ats_masters; enum arm_smmu_domain_stage stage; union { @@ -1531,7 +1532,16 @@ static int arm_smmu_atc_inv_domain(struct arm_smmu_domain *smmu_domain, struct arm_smmu_cmdq_ent cmd; struct arm_smmu_master *master; - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS)) + /* + * The protectiom of spinlock(&iommu_domain->devices_lock) is omitted. + * Because for a given master, its map/unmap operations should only be + * happened after it has been attached and before it has been detached. + * So that, if at least one master need to be atc invalidated, the + * value of smmu_domain->nr_ats_masters can not be zero. + * + * This can alleviate performance loss in multi-core scenarios. + */ + if (!smmu_domain->nr_ats_masters) return 0; arm_smmu_atc_inv_to_cmd(ssid, iova, size, &cmd); @@ -1913,6 +1923,7 @@ static void arm_smmu_detach_dev(struct arm_smmu_master *master) spin_lock_irqsave(&smmu_domain->devices_lock, flags); list_del(&master->domain_head); + smmu_domain->nr_ats_masters--; spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); master->domain = NULL; @@ -1968,6 +1979,7 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) spin_lock_irqsave(&smmu_domain->devices_lock, flags); list_add(&master->domain_head, &smmu_domain->devices); + smmu_domain->nr_ats_masters++; spin_unlock_irqrestore(&smmu_domain->devices_lock, flags); out_unlock: mutex_unlock(&smmu_domain->init_mutex);
When (smmu_domain->smmu->features & ARM_SMMU_FEAT_ATS) is true, even if a smmu domain does not contain any ats master, the operations of arm_smmu_atc_inv_to_cmd() and lock protection in arm_smmu_atc_inv_domain() are always executed. This will impact performance, especially in multi-core and stress scenarios. For my FIO test scenario, about 8% performance reduced. In fact, we can use a struct member to record how many ats masters that the smmu contains. And check that without traverse the list and check all masters one by one in the lock protection. Fixes: 9ce27afc0830 ("iommu/arm-smmu-v3: Add support for PCI ATS") Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> --- drivers/iommu/arm-smmu-v3.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) -- 1.8.3