Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Apr 2001 10:35:32 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        current@FreeBSD.ORG, terry@lambert.org
Subject:   Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable
Message-ID:  <Pine.BSF.4.21.0104251003550.19737-100000@besplex.bde.org>
In-Reply-To: <200104241859.LAA02506@usr08.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104251003550.19737-100000>