slab: Add tracing infrastructure for allocs and frees
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 9 Oct 2018 21:23:02 +0000 (17:23 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 9 Oct 2018 21:45:56 +0000 (17:45 -0400)
commit080a0a8bc20ccd9a7378c0600de68a5fd2e39253
treeccd0a2c92a7aee6394c1272afa4ca21da9b41f11
parentdbeec102964d68ba78c3d2d8364fa0ee9616ab03
slab: Add tracing infrastructure for allocs and frees

When tracking down memory leaks, it is helpful to know if we have
allocated anything that was not freed.

Kmem tracing tracks all allocations (and their backtraces) and drops
those traces when the object is freed.  This tracing happens *above* the
magazine layer, so you're seeing the actual allocs/frees.  You don't
need to worry about objects hanging out in the depots.  Although
stranding resources in depots is a memory management concern, it's not a
memory leak from the user of the allocator.

You can target specific caches (slab allocators) for a more fine-grained
trace - and one that may avoid false positives.

In general, you watch #men/kmemstat or slab_stats to find what is
growing that you don't expect.  Then you trace it, run a test that
shouldn't increase the memory load, stop the trace, and dump the info.

You can expect a trace to not increase the load if all new processes are
destroyed and all files are either already in the page cache or are
flushed.  For the most part, a single go test does this.  You might get
a few kstack allocations, since kernel stacks aren't bound to particular
processes.

Note that we locklessly peek at kmc->flags.  That global memory access
happens on every alloc and free, including the per-core allocations,
even when tracing is off.  I'd prefer it to be as lightweight as
possible so we're less inclined to build with tracing turned off.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/include/slab.h
kern/src/slab.c