From owner-freebsd-current Tue Apr 24 17:36:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 89DF737B422 for ; Tue, 24 Apr 2001 17:36:40 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id KAA06959; Wed, 25 Apr 2001 10:36:33 +1000 Date: Wed, 25 Apr 2001 10:35:32 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Terry Lambert Cc: current@FreeBSD.ORG, terry@lambert.org Subject: Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable In-Reply-To: <200104241859.LAA02506@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 24 Apr 2001, Terry Lambert wrote: > It seems to me that these things are not boot-time tunable, and > should be (really, they should be runtime tunable, but there $ sysctl -a | grep maxf kern.maxfiles: 360 kern.maxfilesperproc: 360 `maxfiles' and `maxfilesperproc' have been runtime tunable for more than 5 years (but there are still bugs in the implementation of this). > are some nasty pageable region allocations for networking that > appear to require contiguous regions for no good reason which I > can discern). That means that the best we can do right now is > boot-time, so here it is: True, things based on stale values of the variables don't work right. > -------------------------------------------------------------------------- > Index: conf/param.c > =================================================================== Don't put anything more in param.c. Almost everything in it can be done better using tunables or sysctls. The only thing that it is now useful for is centralizing the #defines for bogus defaults based on MAXUSERS. This is unnecessary for tunables, since they don't need static initializers. E.g., the tunable for kern.maxfiles can be TUNABLE_INT_DECL("kern.maxfiles", 2 * maxproc, maxfiles); instead of TUNABLE_INT_DECL("kern.maxfiles", MAXFILES, maxfiles); Then maxfiles can be declared in the right place (not here). There would be a problem getting tunables set in the right order if maxproc were tunable. We also have a sysctl for maxproc, but it was made read-only due to allocation problems for exec_map which went away long ago. Apparently the allocation problems for maxfiles and maxfilesperproc aren't so serious, since the sysctls for these have always been read-write. The problems with these sysctls are more with their interactions with setrlimit(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message