public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [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

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