From: dledford@dialnet.net (Doug Ledford)
Newsgroups: comp.os.linux.development.system
Subject: Kernel Tuning
Date: 13 Mar 1996 08:53:30 GMT
Organization: Digital Internet Access Link, Inc. Springfield, MO 873-DIAL
Lines: 37
Message-ID: <4i62ea$3lo@news.dialnet.net>
NNTP-Posting-Host: news.dialnet.net
X-Newsreader: TIN [UNIX 1.3 BETA-950824-color PL0]
In my past experience, tuning linux kernel parameters is a little bit of
a black magic art. What I'm curious about is the possibilty of creating
something like the folowing:
/usr/src/linux/include/linux/ktune.h
This file would include defines for tunable parameters such as NR_FILE,
NR_INODE, NR_OPEN, FD_BITS, MAX_TASKS, MAX_USER_TASKS, and other
parameters that allow a person to tune the kernel for larger systems. I
realize that some of this has been put into the /proc/sys/kernel
directory (for example file_max and inode_max) but it by no means
includes all of it. By putting these valuse into a single header file,
the make config program could be modified to allow a person to change
these values from their default without necessarily knowing the file to
modify (for instance, right now, every time I get new kernel source I
need to modify linux/net.h linux/fs.h linux/limits.h linux/tasks.h). Any
tuneable parameters that effect specific architectures could be placed in
/usr/src/linux/include/asm/ktune.h and #included into to first file. In
this way, we could make kernel tuning much easier than it currently is,
and we could also make it so that you don't have to modify each value in
an rc script file at boot up in the /proc filesystem. Not to mention
that some limits are very hard to dynamically change (such as NR_OPEN).
Anyway, this is just something that I thought, as the number of Linux
users doing things with Linux besides personal workstations grows, might
need to be considered.
As a further note, it might be nice to have the ktune mods done in a
separate program from make config. Maybe a make tune? And I would like
to add a few things in particular to the above list of parameters. I
think all user programs running with UID other than root should have some
mechanism by which their memory usage can be limited. I haven't seen
this yet (I may have overlooked it). I had a user put a fork bomb onto
one of my systems just to annoy me and my other users (I'm Senior System
Administrator for Digital Internet Access Link). I limited the
NR_USER_TASKS to less than half of the total (other wise two telnets in
and a user could bring my system to a HALT), but his fork bomb also
included repetitive malloc(10000) with no freeing of memory. I would
like to be able to keep this type of program from, in the future, forking
until there are 32 copies - login shell (32 is MAX_USER_TASKS) all going
through a repeated loop of fail to fork, malloc another 10000, repeat
while loop. His actual code was like this:
while ( 1==1 ) {
fork("./program");
malloc(10000);
}
That's pretty much it (I may have left some out since I'm not looking at
the source right now). As a final note, when reading through the post on
the new posix spec and the needed code to support it, there was the idea
that user processes only be allowed to lock 4 pages per process from
swapping, this is a bad idea in my opinion, unless you also limit the
total number of unswappable pages per user id amongst all user processes
of that user id. With enough programs running (like the above fork
bomb), locking 4 pages each could cause someone to be able to deadlock
your RAM without getting into swap.....bad, bad, and double bad!
Thanks for listening.
*****************************************************************************
* Doug Ledford * Unix, Novell, Dos, Windows 3.x, *
* dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician *
* PPP access $14.95/month *****************************************
* Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
* communities. Sign-up online at * Web page creation and hosting, other *
* 873-9000 V.34 * services available, call for info. *
*****************************************************************************