Messages in this thread | | | Subject | Re: How to increse [sic.] max open files? | From | Andi Kleen <> | Date | 07 Jan 1997 16:31:45 +0100 |
| |
smurf@work.smurf.noris.de (Matthias Urlichs) writes:
> In linux.dev.kernel, article <5andlm$ikg@palladium.transmeta.com>, > hpa@transmeta.com (H. Peter Anvin) writes: > > By author: yuri@rgti.com (yuri mironoff) > > > > > > Forgive my ignorance but why not implement dynamic file descriptor > > > allocation??? All these arguments about a maximum NR_OPEN would then > > > become inconsequential. > > > > It ain't so easy, and it's BSD's fault. select() has a very nice way > > to ensure that a bitmask of file descriptors is the right size, but > > the FD_* support routines immediately bungles that very nice idea by > > effectively requiring the maximum number of file descriptors > > (technically, the largest possible numerical value of a file > > descriptor) to be known at compile time. There is no way in C to > > This is the kernel mailing list. The first step is to fix the kernel, > including 2.0.27+, to support "unlimited" fd_sets. This hasn't happened > yet. (Somebody said he's working on this..?)
I have a select() routine now that supports unlimited fd_sets (better ulimited NR_OPEN). I also have some patches that add a per process nr_open with a /proc/sys/kernel/nr-open, so you can just do echo 8192 >/proc/sys/kernel/nr-open and all processes forked after this will have a bigger file table. You still have to recompile the applications of course, when you want NR_OPEN > 1024 but that's painless (just add -D__FD_SETSIZE=4096 to CFLAGS). When anybody is interested in alpha patches mail me. It works on my machine but is not extensively tested.
What I would like to see in 2.1 was the addition of poll() to the standard kernel. The sparc port already has it (in arch/sparc/kernel/sys_sunos.c), iBCS has it too, only native i386 Linux programs can't use it. The poll() interface supports an arbitary number of fds.
-Andi
> > After that has happened, we can think about application programs. > Most programs won't ever open more files than the default FD_SETSIZE. > Those that do should just define a reasonable maximum they can handle, > or allocate the fd_set buffers themselves (it's not that difficult even if > you don't use C++). > > -- > For the first time we have a weapon that nobody has used for thirty years. > This gives me great hope for the human race. > --Harlan Ellison > -- > Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg > Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de > 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing > PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE > Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42
| |