Expertise required:USB bulk-throughput and memory leak detection

Expertise required:USB bulk-throughput and memory leak detection

[bhuvan.kumarmital]

 

> -----Original Message-----
> From: Bhuvan Kumarmital (WT01 - Semiconductors & Consumer 
> Electronics) 
> To: 'kernelnewbies@nl.linux.org'
> Subject: Expertise required:USB bulk-throughput and memory 
> leak detection 
> 
>  
>     My team is developing a device driver for a PCMCIA based 
> USB device. We're currently trying to test the performance of 
> our driver. However we're unable to figure out a reliable methods of:
> 1.) detecting memory leaks caused by our driver code. 
> 2.) Neither have we been able to find a tool which shows % 
> utilisation of kernel memory used by our driver.(kernel 
> memory monitoring)
> 3.) Throughput calculation of bulk data transfer is also not 
> precise. We still rely on measuring time on stop watch, while 
> Transferring data.
>  
> About the memory monitoring, there are quite a few tools 
> available at the application level (like free and top which 
> are available with the operating system itself). But none for 
> the kernel level. 
>  
> Please suggest other feasible ways of detecting leaks and 
> monitoring kernel memory utilisation for kernel 2.6.15.4 on 
> fedora core 4.
>  

Re: Expertise required:USB bulk-throughput and memory leak detection

[Arjan van de Ven]

On Mon, 2006-06-26 at 15:50 +0530, bhuvan.kumarmital@wipro.com wrote:
>  
> 

you made the same mistake here as on kernelnewbies.. you didn't post a
pointer to the source code ;)


> > -----Original Message-----
> > From: Bhuvan Kumarmital (WT01 - Semiconductors & Consumer 
> > Electronics) 
> > To: 'kernelnewbies@nl.linux.org'
> > Subject: Expertise required:USB bulk-throughput and memory 
> > leak detection 
> > 
> >  
> >     My team is developing a device driver for a PCMCIA based 
> > USB device. We're currently trying to test the performance of 
> > our driver. However we're unable to figure out a reliable methods of:
> > 1.) detecting memory leaks caused by our driver code. 
> > 2.) Neither have we been able to find a tool which shows % 
> > utilisation of kernel memory used by our driver.(kernel 
> > memory monitoring)
> > 3.) Throughput calculation of bulk data transfer is also not 
> > precise. We still rely on measuring time on stop watch, while 
> > Transferring data.
> >  
> > About the memory monitoring, there are quite a few tools 
> > available at the application level (like free and top which 
> > are available with the operating system itself). But none for 
> > the kernel level. 
> >  
> > Please suggest other feasible ways of detecting leaks and 
> > monitoring kernel memory utilisation for kernel 2.6.15.4 on 
> > fedora core 4.
> >  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Expertise required:USB bulk-throughput and memory leak detection

[Michael Richardson]

bhuvan.kumarmital@wipro.com wrote:
> 1.) detecting memory leaks caused by our driver code. 

Your code will of course be allocating buffers. If you are allocating
from a specific slab, if you have leaks, they will show up in /proc/slabinfo

I wrote some code last month, which I called slabwatch, to track each
item from slabinfo over time and let me plot it. I knew I had a memory leak
which under heavy (network) test loads eventually brought down the kernel,
and I was able to determine what was leaking, and eventually where the leak was.

http://www.sandelman.ca/software/slabwatch-1.3.tgz

It's very rudamentary.

> 2.) Neither have we been able to find a tool which shows % 
> utilisation of kernel memory used by our driver.(kernel 
> memory monitoring)

if you know what pools you are allocating from, then you should be able
to see what is going on. If you are able to, you may want to allocate
(at least experimentally), your own slab, because then you can see precisely
what is going on. This isn't trivial for skb allocations, because you have
to use a custom destructor for the skb, as kfree_skb() otherwise would free
things into the wrong slab.

I wouldn't have minded having a per-interface pool of memory
(and I can see a lot of uses where it would be valuable to limit skb's
allocated to the capture port of a snort sensor, for instance, while not
starving the management port), but I don't know if the skb->destructor is sufficient
under-used to permit such a thing to be trivially implemented.

I don't know the situation with USB drivers.