From: Nate Watterson <nwatters@codeaurora.org>
To: Robin Murphy <robin.murphy@arm.com>,
Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>,
joro@8bytes.org, will.deacon@arm.com
Cc: lorenzo.pieralisi@arm.com, Jayachandran.Nair@cavium.com,
Ganapatrao.Kulkarni@cavium.com, ard.biesheuvel@linaro.org,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/1] iommu/iova: Make rcache flush optional on IOVA allocation failure
Date: Mon, 18 Sep 2017 22:57:32 -0400 [thread overview]
Message-ID: <da87f76b-bcd4-ace8-4dd6-166dfde136e3@codeaurora.org> (raw)
In-Reply-To: <250f41c9-fb37-49b7-c336-68e163f77e16@arm.com>
Hi Tomasz,
On 9/18/2017 12:02 PM, Robin Murphy wrote:
> Hi Tomasz,
>
> On 18/09/17 11:56, Tomasz Nowicki wrote:
>> Since IOVA allocation failure is not unusual case we need to flush
>> CPUs' rcache in hope we will succeed in next round.
>>
>> However, it is useful to decide whether we need rcache flush step because
>> of two reasons:
>> - Not scalability. On large system with ~100 CPUs iterating and flushing
>> rcache for each CPU becomes serious bottleneck so we may want to deffer it.
s/deffer/defer
>> - free_cpu_cached_iovas() does not care about max PFN we are interested in.
>> Thus we may flush our rcaches and still get no new IOVA like in the
>> commonly used scenario:
>>
>> if (dma_limit > DMA_BIT_MASK(32) && dev_is_pci(dev))
>> iova = alloc_iova_fast(iovad, iova_len, DMA_BIT_MASK(32) >> shift);
>>
>> if (!iova)
>> iova = alloc_iova_fast(iovad, iova_len, dma_limit >> shift);
>>
>> 1. First alloc_iova_fast() call is limited to DMA_BIT_MASK(32) to get
>> PCI devices a SAC address
>> 2. alloc_iova() fails due to full 32-bit space
>> 3. rcaches contain PFNs out of 32-bit space so free_cpu_cached_iovas()
>> throws entries away for nothing and alloc_iova() fails again
>> 4. Next alloc_iova_fast() call cannot take advantage of rcache since we
>> have just defeated caches. In this case we pick the slowest option
>> to proceed.
>>
>> This patch reworks flushed_rcache local flag to be additional function
>> argument instead and control rcache flush step. Also, it updates all users
>> to do the flush as the last chance.
>
> Looks like you've run into the same thing Nate found[1] - I came up with
> almost the exact same patch, only with separate alloc_iova_fast() and
> alloc_iova_fast_noretry() wrapper functions, but on reflection, just
> exposing the bool to callers is probably simpler. One nit, can you
> document it in the kerneldoc comment too? With that:
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> Thanks,
> Robin.
>
> [1]:https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg19758.html
This patch completely resolves the issue I reported in [1]!!
Tested-by: Nate Watterson <nwatters@codeaurora.org>
Thanks,
Nate
>
>>
>> Signed-off-by: Tomasz Nowicki <Tomasz.Nowicki@caviumnetworks.com>
>> ---
>> drivers/iommu/amd_iommu.c | 5 +++--
>> drivers/iommu/dma-iommu.c | 6 ++++--
>> drivers/iommu/intel-iommu.c | 5 +++--
>> drivers/iommu/iova.c | 7 +++----
>> include/linux/iova.h | 5 +++--
>> 5 files changed, 16 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
>> index 8d2ec60..ce68986 100644
>> --- a/drivers/iommu/amd_iommu.c
>> +++ b/drivers/iommu/amd_iommu.c
>> @@ -1604,10 +1604,11 @@ static unsigned long dma_ops_alloc_iova(struct device *dev,
>>
>> if (dma_mask > DMA_BIT_MASK(32))
>> pfn = alloc_iova_fast(&dma_dom->iovad, pages,
>> - IOVA_PFN(DMA_BIT_MASK(32)));
>> + IOVA_PFN(DMA_BIT_MASK(32)), false);
>>
>> if (!pfn)
>> - pfn = alloc_iova_fast(&dma_dom->iovad, pages, IOVA_PFN(dma_mask));
>> + pfn = alloc_iova_fast(&dma_dom->iovad, pages,
>> + IOVA_PFN(dma_mask), true);
>>
>> return (pfn << PAGE_SHIFT);
>> }
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index 191be9c..25914d3 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -370,10 +370,12 @@ static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain *domain,
>>
>> /* Try to get PCI devices a SAC address */
>> if (dma_limit > DMA_BIT_MASK(32) && dev_is_pci(dev))
>> - iova = alloc_iova_fast(iovad, iova_len, DMA_BIT_MASK(32) >> shift);
>> + iova = alloc_iova_fast(iovad, iova_len,
>> + DMA_BIT_MASK(32) >> shift, false);
>>
>> if (!iova)
>> - iova = alloc_iova_fast(iovad, iova_len, dma_limit >> shift);
>> + iova = alloc_iova_fast(iovad, iova_len, dma_limit >> shift,
>> + true);
>>
>> return (dma_addr_t)iova << shift;
>> }
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 05c0c3a..75c8320 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -3460,11 +3460,12 @@ static unsigned long intel_alloc_iova(struct device *dev,
>> * from higher range
>> */
>> iova_pfn = alloc_iova_fast(&domain->iovad, nrpages,
>> - IOVA_PFN(DMA_BIT_MASK(32)));
>> + IOVA_PFN(DMA_BIT_MASK(32)), false);
>> if (iova_pfn)
>> return iova_pfn;
>> }
>> - iova_pfn = alloc_iova_fast(&domain->iovad, nrpages, IOVA_PFN(dma_mask));
>> + iova_pfn = alloc_iova_fast(&domain->iovad, nrpages,
>> + IOVA_PFN(dma_mask), true);
>> if (unlikely(!iova_pfn)) {
>> pr_err("Allocating %ld-page iova for %s failed",
>> nrpages, dev_name(dev));
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index f88acad..1a18b14 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -358,9 +358,8 @@ EXPORT_SYMBOL_GPL(free_iova);
>> */
>> unsigned long
>> alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>> - unsigned long limit_pfn)
>> + unsigned long limit_pfn, bool flush_rcache)
>> {
>> - bool flushed_rcache = false;
>> unsigned long iova_pfn;
>> struct iova *new_iova;
>>
>> @@ -373,11 +372,11 @@ alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>> if (!new_iova) {
>> unsigned int cpu;
>>
>> - if (flushed_rcache)
>> + if (!flush_rcache)
>> return 0;
>>
>> /* Try replenishing IOVAs by flushing rcache. */
>> - flushed_rcache = true;
>> + flush_rcache = false;
>> for_each_online_cpu(cpu)
>> free_cpu_cached_iovas(cpu, iovad);
>> goto retry;
>> diff --git a/include/linux/iova.h b/include/linux/iova.h
>> index 58c2a36..8fdcb66 100644
>> --- a/include/linux/iova.h
>> +++ b/include/linux/iova.h
>> @@ -97,7 +97,7 @@ struct iova *alloc_iova(struct iova_domain *iovad, unsigned long size,
>> void free_iova_fast(struct iova_domain *iovad, unsigned long pfn,
>> unsigned long size);
>> unsigned long alloc_iova_fast(struct iova_domain *iovad, unsigned long size,
>> - unsigned long limit_pfn);
>> + unsigned long limit_pfn, bool flush_rcache);
>> struct iova *reserve_iova(struct iova_domain *iovad, unsigned long pfn_lo,
>> unsigned long pfn_hi);
>> void copy_reserved_iova(struct iova_domain *from, struct iova_domain *to);
>> @@ -151,7 +151,8 @@ static inline void free_iova_fast(struct iova_domain *iovad,
>>
>> static inline unsigned long alloc_iova_fast(struct iova_domain *iovad,
>> unsigned long size,
>> - unsigned long limit_pfn)
>> + unsigned long limit_pfn,
>> + bool flush_rcache)
>> {
>> return 0;
>> }
>>
>
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2017-09-19 2:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 10:56 [PATCH 0/1] Optimise IOVA allocations for PCI devices Tomasz Nowicki
2017-09-18 10:56 ` [PATCH 1/1] iommu/iova: Make rcache flush optional on IOVA allocation failure Tomasz Nowicki
2017-09-18 16:02 ` Robin Murphy
2017-09-19 2:57 ` Nate Watterson [this message]
2017-09-19 8:10 ` Tomasz Nowicki
2017-09-19 8:03 ` Tomasz Nowicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da87f76b-bcd4-ace8-4dd6-166dfde136e3@codeaurora.org \
--to=nwatters@codeaurora.org \
--cc=Ganapatrao.Kulkarni@cavium.com \
--cc=Jayachandran.Nair@cavium.com \
--cc=ard.biesheuvel@linaro.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=robin.murphy@arm.com \
--cc=tomasz.nowicki@caviumnetworks.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox