From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 22:12: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 8F6F516A4CE for ; Tue, 19 Oct 2004 22:12:13 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33A1B43D46 for ; Tue, 19 Oct 2004 22:12:13 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9JMC0lg082942; Tue, 19 Oct 2004 18:12:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9JMC0rS082939; Tue, 19 Oct 2004 18:12:00 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 19 Oct 2004 18:12:00 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <16757.36934.576905.271257@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:12:13 -0000 On Tue, 19 Oct 2004, Andrew Gallatin wrote: > > 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 :-( 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. > 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research