From owner-cvs-all Fri Nov 30 22:36:25 2001 Delivered-To: cvs-all@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 8BA0937B41A; Fri, 30 Nov 2001 22:36:09 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fB16jGA43722; Sat, 1 Dec 2001 01:45:16 -0500 (EST) (envelope-from bmilekic) Date: Sat, 1 Dec 2001 01:45:16 -0500 From: Bosko Milekic To: Luigi Rizzo Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_mbuf.c src/sys/vm vm_kern.c Message-ID: <20011201014516.A43490@technokratis.com> References: <200112010021.fB10LUW84726@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112010021.fB10LUW84726@freefall.freebsd.org>; from luigi@FreeBSD.org on Fri, Nov 30, 2001 at 04:21:30PM -0800 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Nov 30, 2001 at 04:21:30PM -0800, Luigi Rizzo wrote: > luigi 2001/11/30 16:21:30 PST > > Modified files: > sys/kern subr_mbuf.c > sys/vm vm_kern.c > Log: > vm/vm_kern.c: rate limit (to once per second) diagnostic printf when > you run out of mbuf address space. This change is pretty useless, for the most part. The message will only be printed a few times, when the map is exhausted, only until mb_alloc() finally calls kmem_malloc() with M_WAITOK and fails, at which point it will mark the "pool" as `exhausted' and stop calling kmem_malloc(), therefore stop printing these messages. However, I do see how it can be useful in the rare case where we get a huge storm of _ONLY_ M_DONTWAIT allocations failing one after the other, without a single M_TRYWAIT allocation in between. > kern/subr_mbuf.c: print a warning message when mb_alloc fails, again > rate-limited to at most once per second. This covers other > cases of mbuf allocation failures. Probably it also overlaps the > one handled in vm/vm_kern.c, so maybe the latter should go away. Yes, it should go away. What it does is suggest that the user increase NMBCLUSTERS and/or MAXUSERS when the truth is that the allocation failure could be the result of malloc() failing during the allocation of the bucket structure, in which case further increasing the size of the mbuf and clust maps would probably make things worse, not better. [...] > Unless there is disagreement (which does not seem to be the case > judging from the discussion on -net so far), and because this is > sort of a safety bugfix, I plan to commit a similar change to STABLE > during the weekend (it affects kern/uipc_mbuf.c there). Heh. The "discussion" on -hackers, -net, or whatever regarding the stack et al so far has been cluttered with such incredible amounts of "crap" that it's difficult to read it all in a single 12 hour period, at least for some of us. :-) > Discussed-with: jlemon, silby and -net > > Revision Changes Path > 1.11 +14 -1 src/sys/kern/subr_mbuf.c > 1.74 +9 -3 src/sys/vm/vm_kern.c Regards, -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message