Wieland Gmeiner <[EMAIL PROTECTED]> writes: > On Thu, 2005-08-18 at 04:05 +0200, Andi Kleen wrote: > > > Is there a realistic use case where this new system call is actually useful > > and solves something that cannot be solved without it? > > As an example: It seems to be a common problem with numerous services to > run out of available file descriptors. There are several workarounds to > this problem, the most common seems to be increasing the systemwide max > number of filedescriptors and restarting the service. If you google for > e.g. 'linux "too many open files"' you get a bunch of mailing list > support requests about that problem.
Consider a process that runs out of fds. If that happens it's already too late - it lost some of its files and is probably in a inconsistent state internally because usually error handling parts for such things are not working very well. The best thing to do is to restart it. The only way to handle it properly would be to constantly monitor the process and then try to increase it shortly before it runs out of fds. First there is no reliable race free way to do this, and if you really do all this overhead then it's far easier to just increase the max number of fds in the first place. In short your new call doesn't solve the problem in a sufficient way. The real fix probably would be to just increase the default limits even further, possible coupled with more aggressive per user memory management. The main reason these limits tends to too small is to avoid a user to fill up kernel memory too much, and there is no global "per user" accounting which accounts all memory used by a user. If that was available the per process limit could be raised much further. And e.g. on 64bit machines there tends to be more usable low mem for these purposes anyways so even without additional accounting the limits could be higher there. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
