On Mon, Aug 24, 2009 at 08:16:42PM +1000, Gavin Maltby wrote:
> Hi
>
> Ian Collins wrote:
> >I'm looking for pointers towards kernel memory debug code.
> >
> >I had a system that periodically ran out of physical memory and froze.
> >It turns out the system had kmem_flags of 0xf and
> >kmem_bufctl_audit_cache usage was getting to about 1.3GB. I'm
> >interested is seeing how this value is used and how it might cause the
> >physical memory exhaustion problem.
>
> There's a chapter on kmem debugging in the mdb (modular debugger) guide
> on docs.sun.com
The basic summary, memory-usage wise, is:
When debugging is enabled, we allocate a 216-byte chunk of memory
*per buffer* in the system. This holds the allocation stack trace.
Every buffer in the system gets a "buffer tag" after the end, which
we use to detect buffer overruns and get fast access to the auditing
chunk, above.
Two large circular logs using up a total of 1/25th of the memory
in the system are allocated, and are used to hold recent activity
and freed buffer contents.
Together, this usually approximately doubles the kernel memory footprint.
The trade-off is that a huge class of bugs are now much easier to find and
diagnose.
Cheers,
- jonathan
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
