Date: Wed, 10 Dec 2008 14:30:24 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: MAXFILES in subr_param.c Message-ID: <ghog9e$r4e$1@ger.gmane.org> In-Reply-To: <863agws2bv.fsf@ds4.des.no> References: <ghjt9l$hg3$1@ger.gmane.org> <863agws2bv.fsf@ds4.des.no>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Dag-Erling Smørgrav wrote:
> 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.
Ok.
>
>> Also, it looks like MAXFILES is used only once, and in a bit funny way:
>>
>> 238 maxfiles = MAXFILES;
>> 239 TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
>> 240 maxprocperuid = (maxproc * 9) / 10;
>> 241 maxfilesperproc = (maxfiles * 9) / 10;
>
> What's funny about it?
MAXFILES is a macro used only once, where it resolves to (maxproc*2).
It's not technically incorrect, but it looks like it adds noise.
>> 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.
Ok.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJP8RyldnAQVacBcgRAiifAKCSk5SrKVscHd7LyeT5D4P++Vpj3gCgtaob
5Zzgh2vQiBDT+DONfM7eKck=
=BZWx
-----END PGP SIGNATURE-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ghog9e$r4e$1>