From owner-freebsd-fs@FreeBSD.ORG Wed May 2 21:27:01 2007 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC08116A402; Wed, 2 May 2007 21:27:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from galileo.cs.uoguelph.ca (galileo.cs.uoguelph.ca [131.104.94.215]) by mx1.freebsd.org (Postfix) with ESMTP id 74F5F13C45B; Wed, 2 May 2007 21:27:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by galileo.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l42LQwXE019553; Wed, 2 May 2007 17:26:59 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l42LS4n15290; Wed, 2 May 2007 17:28:04 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 2 May 2007 17:28:04 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: Robert Watson In-Reply-To: <20070502154934.E30345@fledge.watson.org> Message-ID: References: <20070407165759.GG8831@cicely12.cicely.de> <20070407180319.GH8831@cicely12.cicely.de> <20070407191517.GN63916@garage.freebsd.pl> <20070407212413.GK8831@cicely12.cicely.de> <20070410003505.GA8189@nowhere> <46365F76.7090708@infidyne.com> <20070430213043.GF67738@garage.freebsd.pl> <463665F2.8090605@infidyne.com> <46373CAD.6000502@infidyne.com> <20070501160213.GA496@xor.obsecurity.org> <20070502154934.E30345@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.215 Cc: Craig Boston , Pawel Jakub Dawidek , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Kris Kennaway Subject: Re: ZFS committed to the FreeBSD base. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2007 21:27:01 -0000 On Wed, 2 May 2007, Robert Watson wrote: [stuff snipped] > > 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". Thanks, rick