* [PATCH] NR_OPEN should be raised a litle bit
@ 2007-11-16 21:53 Eric Dumazet
2007-11-16 23:49 ` Alan Cox
0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2007-11-16 21:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux kernel
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Time has come to change NR_OPEN value, some production servers hit the
not so 'ridiculously high value' of 1024*1024 file descriptors per process.
This is safe to raise this value, because alloc_fd_array() uses
vmalloc() for large arrays and vmalloc() returns NULL if a too large
allocation is attempted (or in case of memory shortage)
Moore law implies this limit should be changed every 1-2 years, and it seems
we forgot doing this for ages.
Even on my old notebook, a process can open 1000000 descriptors without any
problem.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: nr_open.patch --]
[-- Type: text/plain, Size: 428 bytes --]
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b3ec4a4..6253ddd 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -21,7 +21,7 @@
/* Fixed constants first: */
#undef NR_OPEN
-#define NR_OPEN (1024*1024) /* Absolute upper limit on fd num */
+#define NR_OPEN (16*1024*1024) /* Absolute upper limit on fd num */
#define INR_OPEN 1024 /* Initial setting for nfile rlimits */
#define BLOCK_SIZE_BITS 10
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] NR_OPEN should be raised a litle bit
2007-11-16 21:53 [PATCH] NR_OPEN should be raised a litle bit Eric Dumazet
@ 2007-11-16 23:49 ` Alan Cox
2007-11-17 9:15 ` Eric Dumazet
0 siblings, 1 reply; 3+ messages in thread
From: Alan Cox @ 2007-11-16 23:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, Linux kernel
On Fri, 16 Nov 2007 22:53:08 +0100
Eric Dumazet <dada1@cosmosbay.com> wrote:
> Time has come to change NR_OPEN value, some production servers hit the
> not so 'ridiculously high value' of 1024*1024 file descriptors per process.
Why fiddle with the kernel defaults when every distribution can manage
this in user space - including picking defaults by memory size or
platform ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] NR_OPEN should be raised a litle bit
2007-11-16 23:49 ` Alan Cox
@ 2007-11-17 9:15 ` Eric Dumazet
0 siblings, 0 replies; 3+ messages in thread
From: Eric Dumazet @ 2007-11-17 9:15 UTC (permalink / raw)
To: Alan Cox; +Cc: Andrew Morton, Linux kernel
Alan Cox a écrit :
> On Fri, 16 Nov 2007 22:53:08 +0100
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>
>> Time has come to change NR_OPEN value, some production servers hit the
>> not so 'ridiculously high value' of 1024*1024 file descriptors per process.
>
> Why fiddle with the kernel defaults when every distribution can manage
> this in user space - including picking defaults by memory size or
> platform ?
Please note I am not speaking about the standard 1024 filedescriptors limit,
but the hardcoded 1024*1024 one.
Tell me more how a user space can overcome this limit ?
Dynamically patching kernel text ?
static struct fdtable * alloc_fdtable(unsigned int nr)
{
...
nr /= (1024 / sizeof(struct file *));
nr = roundup_pow_of_two(nr + 1);
nr *= (1024 / sizeof(struct file *));
if (nr > NR_OPEN)
nr = NR_OPEN;
and :
int expand_files(struct files_struct *files, int nr)
{
struct fdtable *fdt;
fdt = files_fdtable(files);
/* Do we need to expand? */
if (nr < fdt->max_fds)
return 0;
/* Can we expand? */
if (nr >= NR_OPEN)
return -EMFILE;
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-11-17 9:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-16 21:53 [PATCH] NR_OPEN should be raised a litle bit Eric Dumazet
2007-11-16 23:49 ` Alan Cox
2007-11-17 9:15 ` Eric Dumazet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox