From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 22:20:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E851616A4CE; Tue, 19 Oct 2004 22:20:42 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DB443D55; Tue, 19 Oct 2004 22:20:42 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i9JMKgJt000549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 18:20:42 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i9JMKbtb044578; Tue, 19 Oct 2004 18:20:37 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16757.37685.44641.533455@grasshopper.cs.duke.edu> Date: Tue, 19 Oct 2004 18:20:37 -0400 (EDT) To: Robert Watson In-Reply-To: References: <16757.36934.576905.271257@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@freebsd.org Subject: Re: mbuf leak with SMP and debug.mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 22:20:43 -0000 Robert Watson writes: > > Yeah -- I've been trying to avoid committing this patch since atomic > operations hurt the P4 quite a bit more than one would hope. We already > do MPSAFE stats in UMA, so an interesting question might be whether these > stats are redundant to stats already gathered and we can use them instead. > One of the theoretical advantages of mbuma is that mbufs become just > another case of existing slab allocated memory resources, so I would think > most of the interesting stats should be there. Getting the stats from uma seems like the right thing to do in the long run, but the atomic stats is a low-risk way to avoid bogus mbuf leak reports from 5.3-RELEASE users. > > I think there may have been a real leak in the past; at least I ran a > > box out of mbufs a week ago. It only came back when I ifconfig'ed down > > my driver, freeing a bunch of mbufs. But this was before green's recent > > mbuf leak fix, and in the middle of driver development. So who knows.. > > If it was with if_em, the queueing bugs that were fixed recently may also > have helped. It was actually with my driver from a week ago. At that point in the development, I would not be surprised by a leak... Drew