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

[Michael Richardson <mcr@sandelman.ca>]

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.

-
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/