[PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

[PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

[Shuah Khan]

Add kernel error message to track iotlb overflow buffer triggers to understand
how often the overflow buffer gets used.

Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
 lib/swiotlb.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 45bc1f8..597d7b9 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -682,6 +682,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
 	if (!map) {
 		swiotlb_full(dev, size, dir, 1);
 		map = io_tlb_overflow_buffer;
+		dev_err(dev, "SWIOTLB is full. Mapping overflow buffer.\n");
 	}
 
 	dev_addr = swiotlb_virt_to_bus(dev, map);
-- 
1.7.9.5

Re: [PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

[Shuah Khan]

On Fri, 2012-08-31 at 18:55 -0600, Shuah Khan wrote:
> Add kernel error message to track iotlb overflow buffer triggers to understand
> how often the overflow buffer gets used.

Does this change look reasonable? My intent is to be able to assess how
often the overflow buffer usage gets triggered.

-- Shuah
> 
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> ---
>  lib/swiotlb.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 45bc1f8..597d7b9 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -682,6 +682,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
>  	if (!map) {
>  		swiotlb_full(dev, size, dir, 1);
>  		map = io_tlb_overflow_buffer;
> +		dev_err(dev, "SWIOTLB is full. Mapping overflow buffer.\n");
>  	}
>  
>  	dev_addr = swiotlb_virt_to_bus(dev, map);

Re: [PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

[Andrew Morton]

On Fri, 31 Aug 2012 18:55:59 -0600
Shuah Khan <shuah.khan@hp.com> wrote:

> Add kernel error message to track iotlb overflow buffer triggers to understand
> how often the overflow buffer gets used.
> 
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> ---
>  lib/swiotlb.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 45bc1f8..597d7b9 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -682,6 +682,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
>  	if (!map) {
>  		swiotlb_full(dev, size, dir, 1);
>  		map = io_tlb_overflow_buffer;
> +		dev_err(dev, "SWIOTLB is full. Mapping overflow buffer.\n");
>  	}
>  
>  	dev_addr = swiotlb_virt_to_bus(dev, map);

hm.  I would view this as a developer-only debugging thing which
shouldn't be present in production code.  Plus there's a potential that
some poor person will have his logs flooded with this message.

A more typical way of handling this would be to increment a stats
counter, accessible in procfs or debugfs.

Re: [PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

[Shuah Khan]

On Tue, 2012-09-04 at 16:28 -0700, Andrew Morton wrote:
> On Fri, 31 Aug 2012 18:55:59 -0600
> Shuah Khan <shuah.khan@hp.com> wrote:
> 
> > Add kernel error message to track iotlb overflow buffer triggers to understand
> > how often the overflow buffer gets used.
> > 
> > Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> > ---
> >  lib/swiotlb.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> > index 45bc1f8..597d7b9 100644
> > --- a/lib/swiotlb.c
> > +++ b/lib/swiotlb.c
> > @@ -682,6 +682,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
> >  	if (!map) {
> >  		swiotlb_full(dev, size, dir, 1);
> >  		map = io_tlb_overflow_buffer;
> > +		dev_err(dev, "SWIOTLB is full. Mapping overflow buffer.\n");
> >  	}
> >  
> >  	dev_addr = swiotlb_virt_to_bus(dev, map);
> 
> hm.  I would view this as a developer-only debugging thing which
> shouldn't be present in production code.  Plus there's a potential that
> some poor person will have his logs flooded with this message.

Yes. I agree.
> 
> A more typical way of handling this would be to increment a stats
> counter, accessible in procfs or debugfs.
> 

Right. I will work on it. Maybe there is a way to combine this with
dma-debug dma mapping error tracking work I am doing - will look into.

-- Shuah