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
--
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,
> 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.
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
On Sat, 2003-11-08 at 14:03, Anton Blanchard wrote:
> Hi Martin,
>
> > 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.
>
> 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.
> 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.
>
> 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...
Based on your guidlines above, we need a number of proc entries more
like:
8192 + 256*NR_CPUS
mh
--
Martin Hicks Wild Open Source Inc.
[email protected] 613-266-2296