From owner-freebsd-current Sat May 16 15:30:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19019 for freebsd-current-outgoing; Sat, 16 May 1998 15:30:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19014 for ; Sat, 16 May 1998 15:30:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id WAA28338; Sat, 16 May 1998 22:30:34 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA00660; Sun, 17 May 1998 00:30:24 +0200 (MET DST) Message-ID: <19980517003024.49844@follo.net> Date: Sun, 17 May 1998 00:30:24 +0200 From: Eivind Eklund To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf param.c src/sys/kern uipc_domain.c uipc_proto.c uipc_socket.c uipc_socket2.c uipc_usrreq.c src/sys/ References: <19980516200156.30364@follo.net> <199805162159.OAA13568@usr02.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199805162159.OAA13568@usr02.primenet.com>; from Terry Lambert on Sat, May 16, 1998 at 09:59:49PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, May 16, 1998 at 09:59:49PM +0000, Terry Lambert wrote: > > To get around that problem, I'd expand the VM space in the top half of > > the kernel ("somewhere suitable") when it looked like we were "close > > to" running out of space (ie, close to the maxsockets case), and > > probably start out with maxsockets somewhat smaller. (There are, of > > course, a lot of opportunities for high-water/low-water mark magic > > around this). > > > > Does it sound doable? > > The protection you would gain is statistical; there would still be > failure races if you did it (consider a low memory condition; just > because you can expand the page mappings doesn't mean that you will > have pages available for them to point to). Sure, it is a race condition for failure - just as the present one is (unless those maxsockets _really_ are the maximum limit for the number that can be needed). However, it would make it much less likely to fail, and if we _can't_ make it impossible to fail it is worthwhile to just better the odds :-) > This is why type stable memory is so annoying. 8-). Can't see that that makes things much different. I'd say this is why having to allocate things in the bottom half of the kernel is annoying. "Got to roll with the punch" etc. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message