From owner-freebsd-current  Sat May 16 11:02:02 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA13988
          for freebsd-current-outgoing; Sat, 16 May 1998 11:02:02 -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 LAA13955
          for <current@FreeBSD.ORG>; Sat, 16 May 1998 11:01:59 -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 SAA22890;
	Sat, 16 May 1998 18:01:58 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.8/8.8.6) id UAA03962;
	Sat, 16 May 1998 20:01:57 +0200 (MET DST)
Message-ID: <19980516200156.30364@follo.net>
Date: Sat, 16 May 1998 20:01:56 +0200
From: Eivind Eklund <eivind@yes.no>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
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/netinet in_pcb.c in_pcb.h ip_divert.c raw_ip.c tcp_subr.c tcp_var.h udp_usrreq.c udp_var.h src/sys/sys socketvar.h un.h ...
References: <199805152011.NAA12272@freefall.freebsd.org> <199805152020.QAA02956@khavrinen.lcs.mit.edu> <19980516132439.41449@follo.net> <199805161751.NAA09343@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <199805161751.NAA09343@khavrinen.lcs.mit.edu>; from Garrett Wollman on Sat, May 16, 1998 at 01:51:48PM -0400
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, May 16, 1998 at 01:51:48PM -0400, Garrett Wollman wrote:
> <<On Sat, 16 May 1998 13:24:39 +0200, Eivind Eklund <eivind@yes.no> said:
> 
> >> This is called `maxsockets', and is currently defined to be the
> >> maximum of `maxfiles' and `nmbclusters'.  Suggestions for a better
> >> value would be appreciated.
> 
> > What would be necessary to make it possible for this to be a dynamic
> > datastructure, instead of having a maximum limit?
> 
> Can't be done.  The limit is there because we can't expand the VM
> space the zone allocator uses at interrupt time.  Dyson can probably
> explain why this is.

As can probably I :-)

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?

Eivind.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message