Date: Thu, 28 Oct 2004 00:53:24 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: mbuf leak with SMP and debug.mpsafenet=1 Message-ID: <20041028045324.GJ93831@green.homeunix.org> In-Reply-To: <16757.37685.44641.533455@grasshopper.cs.duke.edu> References: <16757.36934.576905.271257@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1041019180828.81058F-100000@fledge.watson.org> <16757.37685.44641.533455@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 19, 2004 at 06:20:37PM -0400, Andrew Gallatin wrote:
>
> 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 ran into this last week and kept wondering how I was losing so many
mbufs, then searching the kernel for possible scenarios... finding none
finally matching up vmstat -z output with netstat -m to clue myself in.
We could really easily just add to netstat -m
warnx("value for SMP systems may be misleading; see manpage");
--
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green@FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041028045324.GJ93831>