[PATCH] NR_OPEN should be raised a litle bit

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 <[email protected]>

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

---

• Follow-Ups:
  • Re: [PATCH] NR_OPEN should be raised a litle bit
    • From: Alan Cox <[email protected]>

• Prev by Date: Re: [PATCH 2/3] mmap: round mmap hint address above mmap_min_addr
• Next by Date: Re: [PATCH 3/3] security: allow capable check to permit mmap or low vm space
• Previous by thread: [PATCH 5/8] UML - Fix page table data sizes
• Next by thread: Re: [PATCH] NR_OPEN should be raised a litle bit
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]