From owner-freebsd-current Mon Jun 26 12:36:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA00154 for current-outgoing; Mon, 26 Jun 1995 12:36:04 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA00147 for ; Mon, 26 Jun 1995 12:36:00 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.11/8.6.6) id PAA12035; Mon, 26 Jun 1995 15:35:37 -0400 From: John Capo Message-Id: <199506261935.PAA12035@irbs.irbs.com> Subject: Re: mb_map full with GATEWAY and maxusers 64! To: tom@uniserve.com (Tom Samplonius) Date: Mon, 26 Jun 1995 15:35:36 -0400 (EDT) Cc: freebsd-current@freefall.cdrom.com (freebsd-current) In-Reply-To: from "Tom Samplonius" at Jun 26, 95 10:32:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1717 Sender: current-owner@FreeBSD.org Precedence: bulk Tom Samplonius writes: > > > On Mon, 26 Jun 1995, =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka Andrey A. Chernov, Black Mage wrote: > > > >I have seen it with maxusers at 48 and 96 on a lightly loaded system. > > >I switched to NMBCLUSTERS=2048 and have not seen it since. > > > > Maybe we need simple increase NMBCLUSTERS calculation as default to > > something like: > > > > #ifdef GATEWAY > > #define NMBCLUSTERS (2048 + maxusers * 16) > > #else > > #define NMBCLUSTERS (1024 + maxusers * 16) > > #endif > > > > Any opinions? > > I think that is too high. Most (all?) users that reported this problem > found that 2048 buffers cured it. Yet your calculcation would give these > users even more buffers that would likely be unneeded. > > As an alternative: > > - document NMBCLUSTERS in LINT (as of 2.0.5R, this still wasn't mentioned) > - include a explicit "options NMBCLUSTERS" line in the GENERIC kernel, > with then note that "mb_map" full indicates that you've run out these buffers > > I would just prefer that this just be documented rather than to bury the > calculation somewhere. > I agree with Tom here. But, it seems to me that there is an underlying problem of some sort. Why do I have to allow for 4Megs of mbuf clusters to service some unknown transient event. Once this memory is in the mbuf map, its there forever. Is this a valid way to examine a running kernel? It appears that it is. gdb -k kernel /dev/mem (kgdb) p mbstat $4 = {m_mbufs = 0, m_clusters = 38, m_spare = 0, m_clfree = 30, m_drops = 0, m_wait = 0, m_drain = 0, m_mtypes = {0, 8, 3, 0, 23, 0, 0, 0, 8, 0 }} (kgdb) p nmbclusters $5 = 2048 (kgdb) -- John Capo