Messages in this thread | | | Date | Sat, 16 Mar 1996 19:48:22 -0600 (CST) | From | Doug Ledford <> | Subject | Kernel Tuning |
| |
This is something I posted about in c.o.l.d.s. The only response I have seen as of about 3 days later was a "Sounds good...Linus?", so I am sending it here to see what the kernel people think since it directly involves their code and work.
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. * *****************************************************************************
| |