Date: Tue, 4 Dec 2001 19:31:49 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Alfred Perlstein <bright@mu.org> Cc: Luigi Rizzo <luigi@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_mbuf.c Message-ID: <20011204193149.A12474@technokratis.com> In-Reply-To: <20011204175837.X92148@elvis.mu.org>; from bright@mu.org on Tue, Dec 04, 2001 at 05:58:37PM -0600 References: <20011203214418.A87350@technokratis.com> <20011203184737.D48755@iguana.aciri.org> <20011203222303.A2690@technokratis.com> <20011203205623.B49974@iguana.aciri.org> <20011204090509.A8591@technokratis.com> <20011204083922.B54383@iguana.aciri.org> <3C0D14AC.412D674C@dsuper.net> <20011204123627.K92148@elvis.mu.org> <20011204180633.A11305@technokratis.com> <20011204175837.X92148@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 04, 2001 at 05:58:37PM -0600, Alfred Perlstein wrote: > * Bosko Milekic <bmilekic@technokratis.com> [011204 17:07] wrote: > > > Please let this just go through at least for the time being. > > > > Alfred, I have NO idea what the heck you're talking about. > > .) We need some way to inform the users that mbuf allocations are > failing. > .) Blindly calling printf(9) in the drivers causes the machines to > DoS themselves. > .) Putting a printf(9) in the mbuf system centralizes this and allows > us to rate limit the amount of carping that occurs when mbufs are > exhausted in a trivial manner for the time being. > > --however-- > > .) It doesn't tell us who is hitting upon the limit. > > So for now it seems quite acceptable. The reason I brought up > __FILE__:__func__ was to suggest it as a possible way to pass > information to the mbuf macros in order to be more explanitory about > where the error was originating from. That's ridiculous. My post had nothing to do with that, or the usage of __FILE__ or whatever other GCCism. What I *WAS* suggesting was that if we ARE going to rate-limit "warning" printf()s that we should do it at the RIGHT places. subr_mbuf.c is not the right place because the only CAUSE of failure that can be FIXED with regards to the mbuf subsystem is the increase of NMBCLUSTERS and, as I've explained so many times before, this case is already accounted for in vm/vm_kern.c - so that leaves us with several other possibilities which I suggested covering in appropriate places, if we were really bent on that, such as the malloc() code, or whatever. Again, I never suggested or implied that we should be inventing ways to determine the cause of the failure from within the mbuf code. > I think I would make sense to change the printf to output once or > maybe every so often "mbuf utilization at 80% suggest increasing > NMBCLUSTERS" rather than waiting for the inevitable explosion > when we hit 100%. The best way to do this, by far, is as Luigi suggested, from userland. A daemon can periodically calculate mbuf map usage and gather data. I had something like this setup a while back and even had graphs generated realtime with mrtg. This way even if you do run out of mbufs and/or clusters, you'll always have the graph to judge whether or not you need to increase NMBCLUSTERS. > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > http://www.morons.org/rants/gpl-harmful.php3 -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011204193149.A12474>