Date: Tue, 19 Oct 2004 18:20:37 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: mbuf leak with SMP and debug.mpsafenet=1 Message-ID: <16757.37685.44641.533455@grasshopper.cs.duke.edu> In-Reply-To: <Pine.NEB.3.96L.1041019180828.81058F-100000@fledge.watson.org> References: <16757.36934.576905.271257@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1041019180828.81058F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16757.37685.44641.533455>