Date: Wed, 25 Apr 2001 19:03:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bde@zeta.org.au (Bruce Evans) Cc: tlambert@primenet.com (Terry Lambert), current@FreeBSD.ORG, terry@lambert.org Subject: Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable Message-ID: <200104251904.MAA00576@usr06.primenet.com> In-Reply-To: <Pine.BSF.4.21.0104251003550.19737-100000@besplex.bde.org> from "Bruce Evans" at Apr 25, 2001 10:35:32 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
IMO, the only useful thing to do with that many file handles
is networking.
The fact that the networking doesn't work right when these values
are turned, because the initial allocations are required to be
contiguous for no good reason to make them pageable, is really,
really stupid.
> > --------------------------------------------------------------------------
> > 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().
Actually, there is a serious problem with this approach when applied
to maxfiles, and I'm not just talking about param.c. The value of
maxfiles is used in:
Tune at File Function
B(1) kern/init_main.c proc0_init()
R kern/kern_descrip.c falloc()
B(2) kern/uipc_socket2.c init_maxsockets()
R svr4/svr4_misc.c svr4_sys_sysconfig()
R(3) svr4/svr4_resource.c svr4_sys_getrlimit()
svr4_sys_getrlimit64()
(1) Before SI_SUB_INTRINSIC, SI_ORDER_FIRST
(2) Before SI_SUB_TUNABLES, SI_ORDER_ANY; setting kern.ipc.maxsockets
in the bootloader does not override this, since the calculation
is:
maxsockets = imax(maxsockets, imax(maxfiles, nmbclusters));
(3) These should really use the rlimit values from the kernel,
instead of accessing maxfiles directly.
The major problem is that the value of maxsockets, derived from the
value of maxfiles, is used in:
kern/uipc_domain.c domaininit()
netinet/tcp_subr.c tcp_init()
netinet/udp_usrreq.c udp_init()
The domaininit() occurs at SI_SUB_PROTO_DOMAIN, SI_ORDER_FIRST; the
other two are from dereferences out of inetsw[] in netinet/in_proto.c.
... all during boot, all to get contiguous swappable regions via calls
to zinit(). So it's not just rlimit()...
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104251904.MAA00576>