From owner-freebsd-hackers Sun Jun 1 18:46:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA18355 for hackers-outgoing; Sun, 1 Jun 1997 18:46:17 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA18350 for ; Sun, 1 Jun 1997 18:46:11 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id LAA03790; Mon, 2 Jun 1997 11:42:42 +1000 Date: Mon, 2 Jun 1997 11:42:42 +1000 From: Bruce Evans Message-Id: <199706020142.LAA03790@godzilla.zeta.org.au> To: jkh@time.cdrom.com, tom@sdf.com Subject: Re: LINT and GENERIC - between a rock and a generic place. Cc: hackers@FreeBSD.ORG, terry@lambert.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Am I right in assuming that the only two items that need to be changable >> are: Not quite. >> - max num of open files (which is based on maxusers now) Already changeable in FreeBSD-2.0 (sysctl -w kern.maxfiles=number). >> - number of mbuf clusters (which is based on maxusers too) This is not easy to change. A special allocation scheme is used for mbufs. Fixed sized structures are allocated for it at boot time. mbufs are never freed. >and CHILD_MAX. Nope, CHILD_MAX is not a tunable parameter (except in certain hacked versions of FreeBSD, not including -2.2.2 or -current). It is the maximum number of child processes per uid on systems (not including BSD) where this limit is a compile-time constant. In BSD, the limit (not CHILD_MAX) can be set at runtime using setrlimit(2). In FreeBSD-2.2.2 and -current, it is normally set per login class in login.conf. Several more limits are based on MAXUSERS: - maxproc. Change it if necessary using sysctl -w kern.maxproc= number. - maxprocperuid. Bogus, should go away. Defaults to 1 less than the value of maxproc. May become the strictest limit if maxproc is increased and the per-process rlimits are not restrictive. This is not likely to be a problem. - maxfilesperproc. Bogus, should go away. Defaults to the same value as maxfiles. May become the strictest limit if maxfiles is increased and and the per-process rlimits are not restrictive. This may be a problem if you start with a small value for maxfiles. - ncallout. Not changable. Should depend on the number of drivers. If maxproc is set to much larger than NPROC, then the system may panic due to too many itimers. Bruce These changes finish nuking CHILD_MAX and OPEN_MAX in -current. diff -c2 param.h~ param.h *** param.h~ Tue Mar 4 03:46:05 1997 --- param.h Tue Mar 4 03:46:23 1997 *************** *** 67,74 **** #define MAXINTERP 32 /* max interpreter file name length */ #define MAXLOGNAME 17 /* max login name length (incl. NUL) */ - #define MAXUPRC CHILD_MAX /* max simultaneous processes */ #define NCARGS ARG_MAX /* max bytes for an exec function */ #define NGROUPS NGROUPS_MAX /* max number groups */ - #define NOFILE OPEN_MAX /* max open files per process */ #define NOGROUP 65535 /* marker for empty group set member */ #define MAXHOSTNAMELEN 256 /* max hostname size */ --- 67,72 ---- diff -c2 syslimits.h~ syslimits.h *** syslimits.h~ Mon Feb 24 00:46:13 1997 --- syslimits.h Mon Feb 24 00:46:14 1997 *************** *** 39,45 **** #define ARG_MAX 65536 /* max bytes for an exec function */ - #ifndef CHILD_MAX - #define CHILD_MAX 40 /* max simultaneous processes */ - #endif #define LINK_MAX 32767 /* max file link count */ #define MAX_CANON 255 /* max bytes in term canon input line */ --- 39,42 ---- *************** *** 47,53 **** #define NAME_MAX 255 /* max bytes in a file name */ #define NGROUPS_MAX 16 /* max supplemental group id's */ - #ifndef OPEN_MAX - #define OPEN_MAX 64 /* max open files per process */ - #endif #define PATH_MAX 1024 /* max bytes in pathname */ #define PIPE_BUF 512 /* max bytes for atomic pipe writes */ --- 44,47 ----