Linux 2.0.x kernel tuning questions (some answers)

Piotr Kapiszewski (kapi@abydos.com)
Sat, 29 Nov 1997 12:07:46 -0500 (EST)


I am not sure how many people have run into limitations of the 2.0.x
kernel (based on defaults in the distribution) but I know I have.
Thus (not being a kernel hacker by a long shot) I set down with a
friend of mine Ed to figure out how to answer the following 3 questions:

Q. How to increase the maximum number of processes available for a user?
Q. How to increase a maximum number of file descriptors available to a
process?
Q. How to increate the system wide maximum number of file descriptors?

After spending several late night/morning hours (best time to do work)
and rebuilding a redhat 4.2 (2.0.30) kernel a few times we come up with
some answers. (yes patching at least to .32 should happen soon here
but it is not relevant to this issue).

Below are results of our findings in a HOWTO kind of format:

-------

Linux 2.0.x kernel tuning
by
Piotr Kapiszewski (kapi@colltech.com)
Ed Markowski (emm@colltech.com)



Q. How to increase the maximum number of processes available for a user?

* 2.0.30 In src/linux/include/linux/fs.h
NR_TASKS variable defines the system wide maximum number of
tasks (processes) available.

NR_TASKS/2 is the number of processes a non-root user can run

NR_TASKS hits a limit somewhere between 2048 and 4096


Q. How to increase a maximum number of file descriptors available to a
process?

2.0.30 In src/linux/include/linux/fs.h
2.0.30 In src/linux/include/linux/limits.h

* this is really messed up it seems (comments in code are strange)

NR_OPEN variable is defined in both files above yet fs.h undef's
it. Thus experimentally I found out that setting this
puppy in both files to the same value controls the
total per process (task) file descriptor limit.

I am guessing it would be bad to set this to something
higher then NR_FILE (in fs.h) ie making it larger then
system wide default.


What is OPEN_MAX? in limits.h (it appears to have no effect)


Q. How to increate the system wide maximum number of file descriptors?

2.0.30 In src/linux/include/linux/fs.h
NR_FILE variable defined a system wide maximum number of file
descriptors available

What is NR_INODE? (why does it need to be larger then NR_FILE)

-----

Could someone with insight take a look at the above and comment on it?
Is this the right way to do it? Some of the patches out there seem to
patch the above but at least I havent found reasonable enough explanations
as to why certain things need to be done a given way.

One of the things which would be very useful in the above is explanation
of limitations and dependencies between some of the above vars. Since
its not always abvious from the comments how things are affected when
values are modified its tricky to hack this in a trial and error style.

Will summerize,

Cheers,
-Kapi

--
Piotr Kapiszewski
kapi@abydos.com					www.abydos.com/~kapi/