Number of proc entries based on NR_CPUS ?
PATCH 1/1 Number of proc entries based on NR_CPUS ?
Here is a patch that makes the number of /proc entries be based on NR_CPUS instead of just having a fixed number. I think it is a good idea now that big Linux machines are starting to appear.
The proper constant and slope of increase are up for argument too.
Patch is against the latest linux-2.5 bk tree.
Opinions?
mh
Signature · 28 lines
Martin Hicks Wild Open Source Inc. [email protected] 613-266-2296 # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1359 -> 1.1360 # include/linux/proc_fs.h 1.27 -> 1.28 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 03/11/08 [email protected] 1.1360 # Make PROC_NDYNAMIC based on NR_CPUS. # -------------------------------------------- # diff -Nru a/include/linux/proc_fs.h b/include/linux/proc_fs.h --- a/include/linux/proc_fs.h Sat Nov 8 12:38:34 2003 +++ b/include/linux/proc_fs.h Sat Nov 8 12:38:34 2003 @@ -27,7 +27,7 @@ /* Finally, the dynamically allocatable proc entries are reserved: */ #define PROC_DYNAMIC_FIRST 4096 -#define PROC_NDYNAMIC 16384 +#define PROC_NDYNAMIC (4096+32*NR_CPUS) #define PROC_SUPER_MAGIC 0x9fa0
Hi Martin,
Quoted 7 lines
Here is a patch that makes the number of /proc entries be based on
NR_CPUSinstead of just having a fixed number. I think it is a good idea now that big Linux machines are starting to appear.The proper constant and slope of increase are up for argument too.
Patch is against the latest linux-2.5 bk tree.
I think I first bumped that to 16k, that was needed on a 32way box. At 128way my gut feeling is its 32k.
Linking the number of proc entries to the number of cpus is a bit crude but its better than having it fixed.
FYI I think some networking people were complaining about this limit when they create gobs of network interfaces (dummy devices? ipsec?). Each interface creates a bunch of /proc/sys/net entries...
Anton
Quoted 6 lines · Anton Blanchard
Hi Martin,
Quoted 4 lines
Here is a patch that makes the number of /proc entries be based on
NR_CPUSinstead of just having a fixed number. I think it is a good idea now that big Linux machines are starting to appear.
Quoted 7 lines
Quoted 3 lines
The proper constant and slope of increase are up for argument too.
Patch is against the latest linux-2.5 bk tree.
I think I first bumped that to 16k, that was needed on a 32way box. At 128way my gut feeling is its 32k.
Okay, those are useful numbers to have. This seems to be higher than what is required by SGI's sn2.
Quoted 2 lines
Linking the number of proc entries to the number of cpus is a bit crude but its better than having it fixed.
Yeah, I'm not sure what a really good solution is. I really don't have an urge to tear apart the proc code to make it more dynamic than this compile time option.
Quoted 4 lines
FYI I think some networking people were complaining about this limit when they create gobs of network interfaces (dummy devices? ipsec?). Each interface creates a bunch of
/proc/sys/netentries...
Based on your guidlines above, we need a number of proc entries more like:
8192 + 256*NR_CPUS
mh
Signature · 2 lines
Martin Hicks Wild Open Source Inc. [email protected] 613-266-2296