Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 1 Dec 2001 01:45:16 -0500
From:      Bosko Milekic <bmilekic@technokratis.com>
To:        Luigi Rizzo <luigi@FreeBSD.org>
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>
In-Reply-To: <200112010021.fB10LUW84726@freefall.freebsd.org>; from luigi@FreeBSD.org on Fri, Nov 30, 2001 at 04:21:30PM -0800
References:  <200112010021.fB10LUW84726@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011201014516.A43490>