Date: Thu, 19 Jun 2003 12:02:09 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: David Schultz <das@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_descrip.c Message-ID: <20030619115532.A629@odysseus.silby.com> In-Reply-To: <20030619082713.GC79448@HAL9000.homeunix.com> References: <200306181857.h5IIvwfY075070@repoman.freebsd.org> <20030619082713.GC79448@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Jun 2003, David Schultz wrote: > Please allow me to re-make the point I believe I made when the > patch was submitted. (Of course, you're welcome to ignore it.) > The reserve should be a tunable constant, not a fixed percentage. > The idea, as I understand, is to allow the administrator to log in > and correct the problem. On a server with 50000 struct files, the > reserve doesn't need to be 2000; a reserve on the order of 100 > open files should be adequate for just about any system. In other > words, the reserve doesn't need to scale with the size of the > system. Your point is good, but not relevant to file descriptors. Why? File descriptors are dynamically allocated. Even if we set maxfiles to 1000000, thereby making the reserve 5 million, we're still not actually wasting anything. Also, the idea of a huge huge reserve isn't necessarily a bad idea; it seems somewhat good that with maxfiles = 50000 that apache / other root daemons can probably run entirely within the reserve, thereby not being susceptible to user interference no matter how many fds are allocated. If we were talking about sockets / procs / anything that used a fixed allocation set at boot time, then I'd agree with you. Oh, btw; while running my fd hog program as root, cron decided to core. Someone should take a look at it and figure out where it doesn't check the return value of something which allocates a fd (or socket?) Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030619115532.A629>