+ nr_open-should-be-raised-a-litle-bit.patch added to -mm tree
Subsystems (5)
[email protected]
tree noticeThe 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 <[email protected]>
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.
---
include/linux/fs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/fs.h renamed from include/linux/fs.h~nr_open-should-be-raised-a-litle-bit +1 -1
@@ -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 [email protected] are
git-net.patch
nr_open-should-be-raised-a-litle-bit.patch
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 get rid of NR_OPEN and introduce a sysctl_nr_open
As changing NR_OPEN from 1024*1024 to 16*1024*1024 was considered a litle bit dangerous, just let it default to 1024*1024 but adds a new sysctl to let sysadmins change this value.
Thank you
[PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
NR_OPEN (historically set to 1024*1024) actually forbids processes to open more than 1024*1024 handles.
Unfortunatly some production servers hit the not so 'ridiculously high value' of 1024*1024 file descriptors per process.
Changing NR_OPEN is not considered safe because of vmalloc space potential exhaust.
This patch introduces a new sysctl (/proc/sys/fs/nr_open) wich defaults to 1024*1024, so that admins can decide to change this limit if their workload needs it.
Documentation/filesystems/proc.txt | 8 ++++++++ Documentation/sysctl/fs.txt | 10 ++++++++++ fs/file.c | 8 +++++--- include/linux/fs.h | 2 +- kernel/sys.c | 2 +- kernel/sysctl.c | 8 ++++++++ 6 files changed, 33 insertions(+), 5 deletions(-)
Documentation/filesystems/proc.txt +8 -0
@@ -989,6 +989,14 @@ nr_inodes Denotes the number of inodes the system has allocated. This number will grow and shrink dynamically. +nr_open +------- + +Denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. + nr_free_inodes --------------
Documentation/sysctl/fs.txt +10 -0
@@ -23,6 +23,7 @@ Currently, these files are in /proc/sys/fs: - inode-max - inode-nr - inode-state +- nr_open - overflowuid - overflowgid - suid_dumpable
@@ -91,6 +92,15 @@ usage of file handles and you don't need to increase the maximum. ============================================================== +nr_open: + +This denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. + +============================================================== + inode-max, inode-nr & inode-state: As with file handles, the kernel allocates the inode structures
fs/file.c +5 -3
@@ -24,6 +24,8 @@ struct fdtable_defer {struct fdtable *next; }; +int sysctl_nr_open__read_mostly =1024 *1024 ; +/* * We use this list to defer free fdtables that have vmalloced * sets/arrays. By keeping a per-cpu list, we avoid having to embed
@@ -147,8 +149,8 @@ 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 ; +if (nr > sysctl_nr_open) + nr = sysctl_nr_open; fdt =kmalloc (sizeof (struct fdtable ),GFP_KERNEL );if (!fdt)
@@ -233,7 +235,7 @@ int expand_files(struct files_struct *files, int nr)if (nr < fdt->max_fds)return 0 ;/* Can we expand? */ -if (nr >=NR_OPEN ) +if (nr >= sysctl_nr_open)return -EMFILE ;/* All good, so we try */
include/linux/fs.h +1 -1
@@ -21,7 +21,7 @@/* Fixed constants first: */ #undef NR_OPEN -#define NR_OPEN (1024*1024)/* Absolute upper limit on fd num */ +extern int sysctl_nr_open;#define INR_OPEN 1024/* Initial setting for nfile rlimits */ #define BLOCK_SIZE_BITS 10
kernel/sys.c +1 -1
@@ -1472,7 +1472,7 @@ asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit __user *rlim)if ((new_rlim.rlim_max > old_rlim->rlim_max) && !capable (CAP_SYS_RESOURCE ))return -EPERM ; -if (resource ==RLIMIT_NOFILE && new_rlim.rlim_max >NR_OPEN ) +if (resource ==RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)return -EPERM ; retval =security_task_setrlimit (resource, &new_rlim);
kernel/sysctl.c +8 -0
@@ -1127,6 +1127,14 @@ static struct ctl_table fs_table[] = { .proc_handler = &proc_dointvec, }, { + .ctl_name = CTL_UNNUMBERED, + .procname = "nr_open", + .data = &sysctl_nr_open, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = FS_DENTRY, .procname = "dentry-state", .data = &dentry_stat,
Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
Quoted 2 lines · Eric Dumazet
Changing
NR_OPENis not considered safe because of vmalloc space potential exhaust.
Verbiage about this point...
Documentation/filesystems/proc.txt nr_inodes · line 999
Quoted 8 lines
Documentation/filesystems/proc.txt +8
-0+nr_open +------- + +Denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. +
should probably be in here - can you add something of the form "Setting this too high can cause vmalloc failures, especially on smaller-RAM machines", and/or *say* how much RAM the default takes? Sure, it's 1M entries, but my tuning on a 2G-RAM machine will differ if these are byte-sized, or 128-byte sized - one is off in a corner, the other is 1/16th of my entire memory.
Also, would it be useful to *lower* the value drastically, if you know a priori that no process should get up to 1K file handles, much less 1M? Does that buy me anything different than setting RLIMIT_NOFILE=1024?
Re: [PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
Quoted 7 lines · [email protected] a écrit :
Quoted 1 line · Eric Dumazet
Changing
NR_OPENis not considered safe because of vmalloc space potential exhaust.Verbiage about this point...
Quoted 14 lines
Documentation/filesystems/proc.txt nr_inodes · line 999
Quoted 8 lines
Documentation/filesystems/proc.txt +8
-0+nr_open +------- + +Denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. +should probably be in here - can you add something of the form "Setting this too high can cause vmalloc failures, especially on smaller-RAM machines", and/or *say* how much RAM the default takes? Sure, it's 1M entries, but my tuning on a 2G-RAM machine will differ if these are byte-sized, or 128-byte sized - one is off in a corner, the other is 1/16th of my entire memory.
vmalloc failures can already happen if you start 32 processes on i386 kernels, each of them wanting to open file handle number 600.000 (if their RLIMIT_NOFILE >= 600000)
fcntl(0, F_DUPFD, 600000);
We are not going to add warnings about vmalloc on every sysctl around there that could allow a root user to exhaust vmalloc space. This is a vmalloc issue on 32bit kernel, and quite frankly I never hit this limit.
If you take a look at vmalloc() implementation, fact that it uses a 'struct vm_struct *vmlist;' to track all active zones show that vmalloc() is not used that much.
Quoted 4 lines
Also, would it be useful to *lower* the value drastically, if you know a priori that no process should get up to 1K file handles, much less 1M? Does that buy me anything different than setting RLIMIT_NOFILE=1024?
NR_OPEN is the max value that RLIMIT_NOFILE can reach, nothing more.
You can set it to 256*1024*1024 or 4*1024 it wont change memory needs on your machine, unless you raise RLIMIT_NOFILE and one of your program leaks file handles, or really want to open simultaneously many of them.
Most programs wont open more than 500 files, so their file table is allocated via kmalloc()
PATCH v2 1/1 get rid of NR_OPEN and introduce a sysctl_nr_open
In reply to Eric DumazetV1->V2
Some NR_OPEN were left unchanged for alpha, mips & sparc64.
As changing NR_OPEN from 1024*1024 to 16*1024*1024 was considered a litle bit dangerous, just let it default to 1024*1024 but adds a new sysctl to let sysadmins change this value.
Thank you
[PATCH] get rid of NR_OPEN and introduce a sysctl_nr_open
NR_OPEN (historically set to 1024*1024) actually forbids processes to open more than 1024*1024 handles.
Unfortunatly some production servers hit the not so 'ridiculously high value' of 1024*1024 file descriptors per process.
Changing NR_OPEN is not considered safe because of vmalloc space potential exhaust.
This patch introduces a new sysctl (/proc/sys/fs/nr_open) wich defaults to 1024*1024, so that admins can decide to change this limit if their workload needs it.
Documentation/filesystems/proc.txt | 8 ++++++++ Documentation/sysctl/fs.txt | 10 ++++++++++ arch/alpha/kernel/osf_sys.c | 2 +- arch/mips/kernel/sysirix.c | 2 +- arch/sparc64/solaris/fs.c | 2 +- arch/sparc64/solaris/timod.c | 6 ++++-- fs/file.c | 8 +++++--- include/linux/fs.h | 2 +- kernel/sys.c | 2 +- kernel/sysctl.c | 8 ++++++++ 10 files changed, 40 insertions(+), 10 deletions(-)
Documentation/filesystems/proc.txt +8 -0
@@ -989,6 +989,14 @@ nr_inodes Denotes the number of inodes the system has allocated. This number will grow and shrink dynamically. +nr_open +------- + +Denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. + nr_free_inodes --------------
Documentation/sysctl/fs.txt +10 -0
@@ -23,6 +23,7 @@ Currently, these files are in /proc/sys/fs: - inode-max - inode-nr - inode-state +- nr_open - overflowuid - overflowgid - suid_dumpable
@@ -91,6 +92,15 @@ usage of file handles and you don't need to increase the maximum. ============================================================== +nr_open: + +This denotes the maximum number of file-handles a process can +allocate. Default value is 1024*1024 (1048576) which should be +enough for most machines. Actual limit depends on RLIMIT_NOFILE +resource limit. + +============================================================== + inode-max, inode-nr & inode-state: As with file handles, the kernel allocates the inode structures
arch/alpha/kernel/osf_sys.c +1 -1
@@ -430,7 +430,7 @@ sys_getpagesize(void)asmlinkage unsigned long sys_getdtablesize (void ) { -return NR_OPEN ; +return sysctl_nr_open; }/*
arch/mips/kernel/sysirix.c +1 -1
@@ -356,7 +356,7 @@ asmlinkage int irix_syssgi(struct pt_regs *regs) retval =NGROUPS_MAX ; goto out;case 5 : - retval =NR_OPEN ; + retval = sysctl_nr_open; goto out;case 6 : retval =1 ;
arch/sparc64/solaris/fs.c +1 -1
@@ -624,7 +624,7 @@ asmlinkage int solaris_ulimit(int cmd, int val)case 3 :/* UL_GMEMLIM */ return current->signal->rlim[RLIMIT_DATA ].rlim_cur;case 4 :/* UL_GDESLIM */ -return NR_OPEN ; +return sysctl_nr_open; }return -EINVAL ; }
arch/sparc64/solaris/timod.c +4 -2
@@ -859,7 +859,8 @@ asmlinkage int solaris_getmsg(unsigned int fd, u32 arg1, u32 arg2, u32 arg3)SOLD ("entry" );lock_kernel (); -if (fd >=NR_OPEN ) goto out; +if (fd >= sysctl_nr_open) + goto out; fdt =files_fdtable (current->files); filp = fdt->fd[fd];
@@ -927,7 +928,8 @@ asmlinkage int solaris_putmsg(unsigned int fd, u32 arg1, u32 arg2, u32 arg3)SOLD ("entry" );lock_kernel (); -if (fd >=NR_OPEN ) goto out; +if (fd >= sysctl_nr_open) + goto out; fdt =files_fdtable (current->files); filp = fdt->fd[fd];
fs/file.c +5 -3
@@ -24,6 +24,8 @@ struct fdtable_defer {struct fdtable *next; }; +int sysctl_nr_open__read_mostly =1024 *1024 ; +/* * We use this list to defer free fdtables that have vmalloced * sets/arrays. By keeping a per-cpu list, we avoid having to embed
@@ -147,8 +149,8 @@ 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 ; +if (nr > sysctl_nr_open) + nr = sysctl_nr_open; fdt =kmalloc (sizeof (struct fdtable ),GFP_KERNEL );if (!fdt)
@@ -233,7 +235,7 @@ int expand_files(struct files_struct *files, int nr)if (nr < fdt->max_fds)return 0 ;/* Can we expand? */ -if (nr >=NR_OPEN ) +if (nr >= sysctl_nr_open)return -EMFILE ;/* All good, so we try */
include/linux/fs.h +1 -1
@@ -21,7 +21,7 @@/* Fixed constants first: */ #undef NR_OPEN -#define NR_OPEN (1024*1024)/* Absolute upper limit on fd num */ +extern int sysctl_nr_open;#define INR_OPEN 1024/* Initial setting for nfile rlimits */ #define BLOCK_SIZE_BITS 10
kernel/sys.c +1 -1
@@ -1472,7 +1472,7 @@ asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit __user *rlim)if ((new_rlim.rlim_max > old_rlim->rlim_max) && !capable (CAP_SYS_RESOURCE ))return -EPERM ; -if (resource ==RLIMIT_NOFILE && new_rlim.rlim_max >NR_OPEN ) +if (resource ==RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)return -EPERM ; retval =security_task_setrlimit (resource, &new_rlim);
kernel/sysctl.c +8 -0
@@ -1127,6 +1127,14 @@ static struct ctl_table fs_table[] = { .proc_handler = &proc_dointvec, }, { + .ctl_name = CTL_UNNUMBERED, + .procname = "nr_open", + .data = &sysctl_nr_open, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = FS_DENTRY, .procname = "dentry-state", .data = &dentry_stat,