ZFS committed to the FreeBSD base.
rmacklem at uoguelph.ca
Wed May 2 21:27:01 UTC 2007
On Wed, 2 May 2007, Robert Watson wrote:
> Historically, such panics have been a result of one of two things:
> (1) An immediate resource leak in UMA(9) or malloc(9) allocated memory.
> (2) Mis-tuning of a resource limit, perhaps due to sizing the limit based on
> solely physical memory size, not taking available kernel address space
> into account.
> mti_stats reports only on malloc(9), you need to also look at uma(9), since
> many frequently allocated types are allocated directly with the slab
> allocator, and not from kernel malloc. Take a look at the output of "show
> uma" or "show malloc" in DDB, or respectively "vmstat -z" and "vmstat -m" on
> a core or on a live system. malloc(9) is actually implemented using two
> different back-ends: UMA-managed fixed size memory buckets for small
> allocations, and direct page allocation for large allocations.
Ok, it does appear I'm leaking NAMEIs. "vmstat -z", which I didn't know
about, was the trick. Handling lookup name buffers is also port specific,
so it wouldn't have shown up in the other ports.
So, forget what I said w.r.t. a MALLOC bug and thanks for the help. I
should be able to locate the leak pretty easily with "vmstat -z".
More information about the freebsd-current