From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 22:08:13 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 3956316A4CE; Tue, 19 Oct 2004 22:08:13 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB9D43D41; Tue, 19 Oct 2004 22:08:12 +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 i9JM8BJt028550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Oct 2004 18:08:11 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i9JM86qt044561; Tue, 19 Oct 2004 18:08:06 -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.36934.576905.271257@grasshopper.cs.duke.edu> Date: Tue, 19 Oct 2004 18:08:06 -0400 (EDT) To: Robert Watson In-Reply-To: References: <16757.34627.710821.812489@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:08:13 -0000 Robert Watson writes: > > On Tue, 19 Oct 2004, Andrew Gallatin wrote: > > > I hooked up the em0 GbE interfaces, and that leaks nearly as bad as my > > myrinet nic (at least with a linux sender, hooked back-to-back). Em0 > > seems to be leaking at a few thoundsand pkts/sec, so I wasn't brave > > enough to do a long run.. > > Oh, I just had a thought. Could you try this patch (perhaps with tweaks > to apply to recent kernels): > > http://www.watson.org/~robert/freebsd/netperf/20040910-atomic-mballoc.diff > > I ran with this change in the netperf branch for quite a long time, but > never managed to trigger sufficient races on the allocator to result in > the counters getting off by more than a couple. However, the reason I > updated the patch and put it on the netperf page was that Bill Paul > reported seeing fairly hefty stats errors on an SMP box at gig-e rates, > and when he tried the patch it went away. It would be useful if you could > try the patch to make sure that we're looking at a real mbuf leak and not > an mbuf stat leak. Aha! That seems to be it (a stats leak). This is kind of a shame, since the last thing a P4 needs is more atomic ops :-( 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.. Drew