Date: Wed, 10 Dec 2008 12:21:24 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: MAXFILES in subr_param.c Message-ID: <863agws2bv.fsf@ds4.des.no> In-Reply-To: <ghjt9l$hg3$1@ger.gmane.org> (Ivan Voras's message of "Mon, 08 Dec 2008 20:41:32 %2B0100") References: <ghjt9l$hg3$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras <ivoras@freebsd.org> writes:
> I'm looking at kern/subr_param.c:
>
> 72 #ifndef MAXFILES
> 73 #define MAXFILES (maxproc * 2)
> 74 #endif
>
> Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?
Even maxproc * 3 won't be enough, unless none of your processes actually
do anything. It's just an arbitrary value, based on the assumption that
you will never have maxproc concurrent processes anyway.
> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>
> 238 maxfiles =3D MAXFILES;
> 239 TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
> 240 maxprocperuid =3D (maxproc * 9) / 10;
> 241 maxfilesperproc =3D (maxfiles * 9) / 10;
What's funny about it?
> Historical reasons?
To a certain degree, yes; MAXFILES used to be a static limit which you
could only change in your kernel config. It is now a loader tunable
(though you can still change the default in your kernel config), so the
MAXFILES macro was replaced with a maxfiles variable wherever it is
used, and the former is now only used to initialize the latter.
DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?863agws2bv.fsf>