diff mbox

iommu/dma: Map scatterlists more parsimoniously

Message ID 104b4682056bc5b4aa0afadd39196c03fc06555d.1447249098.git.robin.murphy@arm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Robin Murphy Nov. 11, 2015, 2:54 p.m. UTC
Whilst blindly assuming the worst case for segment boundaries and
aligning every segment individually is safe from the point of view
of respecting the device's parameters, it is also undeniably a waste
of IOVA space. Futhermore, the knock-on effects of more pages than
necessary being exposed to device access, additional overhead in page
table updates and TLB invalidations, etc., are even more undesirable.

Improve matters by taking the actual boundary mask into account to
actively detect the cases in which we really do need to adjust a
segment, and avoid wasting space in the remainder.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

Hi all,

I've given this some brief testing on Juno with USB and (via magic
PCI hacks) SATA to confirm that all the +1s and -1s at least seem to
be in the right places, so I'm throwing it out now for a head-start on
checking whether it also helps the media folks with the v4l portability
issues they're up against (I'm confident it should). If all goes well I
figure I'll repost next week based on rc1 instead of some random local
development commit.

Robin.

 drivers/iommu/dma-iommu.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

Comments

Yong Wu (吴勇) Nov. 12, 2015, 5:47 a.m. UTC | #1
On Wed, 2015-11-11 at 14:54 +0000, Robin Murphy wrote:
> Whilst blindly assuming the worst case for segment boundaries and
> aligning every segment individually is safe from the point of view
> of respecting the device's parameters, it is also undeniably a waste
> of IOVA space. Futhermore, the knock-on effects of more pages than
> necessary being exposed to device access, additional overhead in page
> table updates and TLB invalidations, etc., are even more undesirable.
> 
> Improve matters by taking the actual boundary mask into account to
> actively detect the cases in which we really do need to adjust a
> segment, and avoid wasting space in the remainder.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> 
> Hi all,
> 
> I've given this some brief testing on Juno with USB and (via magic
> PCI hacks) SATA to confirm that all the +1s and -1s at least seem to
> be in the right places, so I'm throwing it out now for a head-start on
> checking whether it also helps the media folks with the v4l portability
> issues they're up against (I'm confident it should). If all goes well I
> figure I'll repost next week based on rc1 instead of some random local
> development commit.
> 
> Robin.

It works well on MT8173. containing
VDA/VEA(VideoDecodeAccelerator/VideoEncodeAccelerator) unit test.

Tested-by: Yong Wu <yong.wu@mediatek.com>

> 
>  drivers/iommu/dma-iommu.c | 19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 3a20db4..821ebc4 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -441,6 +441,7 @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
>  	struct scatterlist *s, *prev = NULL;
>  	dma_addr_t dma_addr;
>  	size_t iova_len = 0;
> +	unsigned long mask = dma_get_seg_boundary(dev);
>  	int i;
>  
>  	/*
> @@ -460,17 +461,19 @@ int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
>  		s->length = s_length;
>  
>  		/*
> -		 * The simple way to avoid the rare case of a segment
> -		 * crossing the boundary mask is to pad the previous one
> -		 * to end at a naturally-aligned IOVA for this one's size,
> -		 * at the cost of potentially over-allocating a little.
> +		 * With a single size-aligned IOVA allocation, no segment risks
> +		 * crossing the boundary mask unless the total size exceeds
> +		 * the mask itself. The simple way to maintain alignment when
> +		 * that does happen is to pad the previous segment to end at the
> +		 * next boundary, at the cost of over-allocating a little.
>  		 */
>  		if (prev) {
> -			size_t pad_len = roundup_pow_of_two(s_length);
> +			size_t pad_len = (mask - iova_len + 1) & mask;
>  
> -			pad_len = (pad_len - iova_len) & (pad_len - 1);
> -			prev->length += pad_len;
> -			iova_len += pad_len;
> +			if (pad_len && pad_len < s_length - 1) {
> +				prev->length += pad_len;
> +				iova_len += pad_len;
> +			}
>  		}
>  
>  		iova_len += s_length;
Daniel Kurtz Dec. 10, 2015, 12:49 p.m. UTC | #2
On Thu, Nov 12, 2015 at 1:47 PM, Yong Wu <yong.wu@mediatek.com> wrote:
> On Wed, 2015-11-11 at 14:54 +0000, Robin Murphy wrote:
>> Whilst blindly assuming the worst case for segment boundaries and
>> aligning every segment individually is safe from the point of view
>> of respecting the device's parameters, it is also undeniably a waste
>> of IOVA space. Futhermore, the knock-on effects of more pages than

"Furthermore" (checkpatch actually caught this, not me ;-) )

>> necessary being exposed to device access, additional overhead in page
>> table updates and TLB invalidations, etc., are even more undesirable.
>>
>> Improve matters by taking the actual boundary mask into account to
>> actively detect the cases in which we really do need to adjust a
>> segment, and avoid wasting space in the remainder.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>
>> Hi all,
>>
>> I've given this some brief testing on Juno with USB and (via magic
>> PCI hacks) SATA to confirm that all the +1s and -1s at least seem to
>> be in the right places, so I'm throwing it out now for a head-start on
>> checking whether it also helps the media folks with the v4l portability
>> issues they're up against (I'm confident it should). If all goes well I
>> figure I'll repost next week based on rc1 instead of some random local
>> development commit.
>>
>> Robin.
>
> It works well on MT8173. containing
> VDA/VEA(VideoDecodeAccelerator/VideoEncodeAccelerator) unit test.
>
> Tested-by: Yong Wu <yong.wu@mediatek.com>

Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Daniel Kurtz Feb. 2, 2016, 7:04 a.m. UTC | #3
On Thu, Dec 10, 2015 at 8:49 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> On Thu, Nov 12, 2015 at 1:47 PM, Yong Wu <yong.wu@mediatek.com> wrote:
>> On Wed, 2015-11-11 at 14:54 +0000, Robin Murphy wrote:
>>> Whilst blindly assuming the worst case for segment boundaries and
>>> aligning every segment individually is safe from the point of view
>>> of respecting the device's parameters, it is also undeniably a waste
>>> of IOVA space. Futhermore, the knock-on effects of more pages than
>
> "Furthermore" (checkpatch actually caught this, not me ;-) )
>
>>> necessary being exposed to device access, additional overhead in page
>>> table updates and TLB invalidations, etc., are even more undesirable.
>>>
>>> Improve matters by taking the actual boundary mask into account to
>>> actively detect the cases in which we really do need to adjust a
>>> segment, and avoid wasting space in the remainder.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>> ---
>>>
>>> Hi all,
>>>
>>> I've given this some brief testing on Juno with USB and (via magic
>>> PCI hacks) SATA to confirm that all the +1s and -1s at least seem to
>>> be in the right places, so I'm throwing it out now for a head-start on
>>> checking whether it also helps the media folks with the v4l portability
>>> issues they're up against (I'm confident it should). If all goes well I
>>> figure I'll repost next week based on rc1 instead of some random local
>>> development commit.
>>>
>>> Robin.
>>
>> It works well on MT8173. containing
>> VDA/VEA(VideoDecodeAccelerator/VideoEncodeAccelerator) unit test.
>>
>> Tested-by: Yong Wu <yong.wu@mediatek.com>
>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>


Did this patch get lost?
Can we pick it up as a fix for v4.5?
diff mbox

Patch

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 3a20db4..821ebc4 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -441,6 +441,7 @@  int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
 	struct scatterlist *s, *prev = NULL;
 	dma_addr_t dma_addr;
 	size_t iova_len = 0;
+	unsigned long mask = dma_get_seg_boundary(dev);
 	int i;
 
 	/*
@@ -460,17 +461,19 @@  int iommu_dma_map_sg(struct device *dev, struct scatterlist *sg,
 		s->length = s_length;
 
 		/*
-		 * The simple way to avoid the rare case of a segment
-		 * crossing the boundary mask is to pad the previous one
-		 * to end at a naturally-aligned IOVA for this one's size,
-		 * at the cost of potentially over-allocating a little.
+		 * With a single size-aligned IOVA allocation, no segment risks
+		 * crossing the boundary mask unless the total size exceeds
+		 * the mask itself. The simple way to maintain alignment when
+		 * that does happen is to pad the previous segment to end at the
+		 * next boundary, at the cost of over-allocating a little.
 		 */
 		if (prev) {
-			size_t pad_len = roundup_pow_of_two(s_length);
+			size_t pad_len = (mask - iova_len + 1) & mask;
 
-			pad_len = (pad_len - iova_len) & (pad_len - 1);
-			prev->length += pad_len;
-			iova_len += pad_len;
+			if (pad_len && pad_len < s_length - 1) {
+				prev->length += pad_len;
+				iova_len += pad_len;
+			}
 		}
 
 		iova_len += s_length;