[EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
