>> You get the lockups because the kernel select() (fs/select.c) routine
>> puts 6 copies of fd_set on the kernel stack. The kernel stack per
>> process on i386 is limited to 4K. With NR_OPEN of 4096, one fd_set is
>> 512bytes. With 6*512bytes you have already overflowed the kernel stack
>> when a process uses select().
>
>I do not understand the relationship of NR_OPEN to the rest of these
>issues. Your message is the closest thing to documentation I have seen.
NR_OPEN is the number of fds a process can open.
>
>> The proper solution would be that
>> sys_select() allocates the fd_set copies dynamically with kmalloc().
>> Someone has to hack this in.
>
>But no one is going to, and I do not have the knowledge to attempt it.
I did a first try, but it locked up my machine and did other harm and
I don't have enough time currently to debug it.
>
>> BTW It's better to use NR_OPEN of 1024 (like Digital Unix or Solaris do).
>> With bigger values the FD_SET(), FD_ZERO() etc. macros in glibc won't work.
>
>I don't understand "why", because I don't know what NR_OPEN does. Would this
>limit me to having only 1024 files per process open?
Yes.
>
>The application is virtual HTTP's (Apache). Apache wants to open 4 log files
>per server. We want to put a 512 servers on a machine. Except for the
>FD limit, we can. We have since decided to only put 300 servers (as an altern
>ative
>to using FreeBSD instead of Linux!), but since we host over 4,000 domains
>we really and truly need a fix for this. A real, proven solution would be
>worth $$$ to our organization.
When you want to pay $$, I'm sure you can find someone on the kernel
mailing list to rework sys_select() and add proper support for NR_OPEN>256
to the kernel. That's how free software works :)
For NR_OPEN>1024 a patch to libc will be needed too I think.
-Andi