From owner-freebsd-current Wed Apr 25 12: 2: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 2897E37B422 for ; Wed, 25 Apr 2001 12:01:58 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id MAA11193; Wed, 25 Apr 2001 12:01:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp05.primenet.com, id smtpdAAAiJaOYv; Wed Apr 25 12:01:44 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA00576; Wed, 25 Apr 2001 12:04:49 -0700 (MST) From: Terry Lambert Message-Id: <200104251904.MAA00576@usr06.primenet.com> Subject: Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable To: bde@zeta.org.au (Bruce Evans) Date: Wed, 25 Apr 2001 19:03:53 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), current@FreeBSD.ORG, terry@lambert.org In-Reply-To: from "Bruce Evans" at Apr 25, 2001 10:35:32 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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