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

* 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