The patch titled
Increase NR_OPEN
has been added to the -mm tree. Its filename is
nr_open-should-be-raised-a-litle-bit.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: Increase NR_OPEN
From: Eric Dumazet <dada1@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Cc: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/fs.h~nr_open-should-be-raised-a-litle-bit include/linux/fs.h
--- a/include/linux/fs.h~nr_open-should-be-raised-a-litle-bit
+++ a/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
_
Patches currently in -mm which might be from dada1@xxxxxxxxxxxxx are
git-net.patch
nr_open-should-be-raised-a-litle-bit.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
