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.

index b3ec4a4..6253ddd 100644
@@ -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

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;