mbuf leak with SMP and debug.mpsafenet=1
Andrew Gallatin
gallatin at cs.duke.edu
Tue Oct 19 15:20:43 PDT 2004
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
More information about the freebsd-current
mailing list