Date: Fri, 12 Feb 1999 16:20:02 -0800 From: "Justin C. Walker" <justin@apple.com> To: Chris Csanady <ccsanady@friley-185-205.res.iastate.edu>, Jason Thorpe <thorpej@nas.nasa.gov> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Serious mbuf cluster leak.. Message-ID: <19990212162002.M5418@apple.com> In-Reply-To: <19990213001613.93D2E10@friley-185-205.res.iastate.edu>; from Chris Csanady on Fri, Feb 12, 1999 at 06:16:13PM -0600 References: <199902122053.MAA04612@lestat.nas.nasa.gov> <19990213001613.93D2E10@friley-185-205.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 12, 1999 at 06:16:13PM -0600, Chris Csanady wrote: > > >On Thu, 11 Feb 1999 09:15:29 -0800 > > "Justin C. Walker" <justin@apple.com> wrote: > > > > > I can say that our implementation doesn't seem to = > > > suffer from this problem. Could be there's an issue in the use of = > > > PRUS_* v. the socket state we use. The code in my kernel looks like: > > > >The NetBSD code looks pretty much just like this, and also does not > >suffer from an mbuf cluster leak of any kind. > > I'll take a look at the NetBSD code when I have a chance. Are you sure > you just have not seen it though? I only see it over gigabit ethernet, > and even then only when doing lots of large writes. Perhaps it is a > timing issue? > > I am only pointing out what I see. It does not happen with source from > before this change--so what else should I think? You are welcome to > take a glance at my driver, although I don't think it is the problem. > There are only 2 places where clusters are touched, and they never > become seperate from the mbuf header. But I don't see any mbuf leak.. Believe me, I understand. We've been beating on this code for months, with 10, 100, and Gigabit networking, using web server, high-volume UDP, file share, and other tests. That's no guarantee, of course, and different setups can manifest different behaviors and bugs. However, I do feel confident that we haven't seen leaks. Those would typically grind the system to a halt, or result in a noticeable downturn in performance, and we just don't see this (or, rather, we know the reasons for the problems we do see :-}). Could well be that there's a subtle difference in the two implementations that shows up this leak under stress. I haven't looked at the code, though, and can't really comment. Well, I could, but it wouldn't help :-} Regards, Justin BTW: I got mildly whacked by The Powers That Probably Are for exhuberance in the use of FreeBSD mailing lists, so I presume one of the lists should be dumped. I'm removing the -current list, but someone might forward if it's of interest. -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking | Men are from Earth. Apple Computer, Inc. | Women are from Earth. 2 Infinite Loop | Deal with it. Cupertino, CA 95014 | *---------------------------------------*------------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990212162002.M5418>