From owner-freebsd-current Tue Oct 6 17:02:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA04420 for freebsd-current-outgoing; Tue, 6 Oct 1998 17:02:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA04371 for ; Tue, 6 Oct 1998 17:02:27 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA11930; Tue, 6 Oct 1998 17:02:21 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd011797; Tue Oct 6 17:02:10 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA11909; Tue, 6 Oct 1998 17:02:03 -0700 (MST) From: Terry Lambert Message-Id: <199810070002.RAA11909@usr04.primenet.com> Subject: Re: -current panics.. To: dg@root.com Date: Wed, 7 Oct 1998 00:02:03 +0000 (GMT) Cc: tlambert@primenet.com, enkhyl@hayseed.net, mishania@demos.net, current@FreeBSD.ORG In-Reply-To: <199810062326.QAA00703@implode.root.com> from "David Greenman" at Oct 6, 98 04:26:05 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >It's always seemed odd to me that there would ever be an "out of > >mbufs!" message when there was, in fact, room available to allocate > >more mbufs... > > The kernel address space and layout is a carefully crafted and tuned > finite resource. There are several cases where decent performance demands > that certain things be statically allocated, and virtual memory for network > buffers is one of those things. I understand the 3.5G/.5G and 2G/2G KVA split... but can't this be implemented using seperate virtual addres spaces? Alternately, 2G is not so small that not having 3.5G would be a bad thing, I think. As for allocation policies: I can also see a reason for a high water mark, so that one subsystem does not monopolize resources, or an implemetnation that "broadcasts" a "give back all the memory you can please" to all subsystems that eat memory. On the other hand, denying resources because of policy rather than technological reasons has always struck me as silly, on the grounds that I might as well be allowed to use resources no one else is using, at least until such time as there's a real shortage. The idea that hard-coded limits should become soft-coded in the absence of resource contention isn't new, and the fact is that it will make a lot of things "just work". I'd much rather a process be killed for being over it's memory quota *only* in a situation where a genuine memory shortage exists, but allowing the process to run otherwise. The mbuf ownership is more problematic, in that we would need to identify a priority list of resource user... for example, you could revoke ownership of FIN_WAIT_2 mbufs, then of TIME_WAIT mbufs, and so on, to recover the resources in a memory shortage situation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message