CSvax:Pucc-H:Physics:crl (11/22/82)
#R:micomvax:-10400:pur-phy:12700007:000:1201 pur-phy!crl Nov 22 10:22:00 1982 We run Berkeley's 2.8bsd and some of the first things we did were: 1) to add a renice system call (so we didn't have to write over /dev/kmem) and 2) to add an autonicing feature. The way it was implemented here was to nice +5 all background jobs when a user logged himself out. Since all we have is a PDP-11/44, we decided that we must give priority to interactive processes, and the best way to do this was to renice background jobs. We looked at basing the renice on CPU time used, length of run, etc., but couldn't think of a very good way to implement this, since all that information is in the user structure which is only available when a process is actually running. Thus, to make the time checks, we'd have to put the code in clock.c at every clock tick. Therefore, we opted to do the background renicing only. It is probably the best thing we ever did. Even though our load occasionally rises to over 5 due to 3 or more background jobs, interactive users rarely get very impacted, which is our desire. Furthermore, the background jobs usually manage to get a fair share or runtime anyways, since those interactive jobs rarely run continuously. Charles LaBrec ... pur-ee!physics:crl
pag@sri-unix (11/23/82)
My implementation of kernel autonice'ing has the following features:
1. UID 0 and sticky text procs are unaffected.
2. nice value increases with accumulated cpu time (up to a maximum
of 50).
3. Autonice'ing is load-based, ie, the higher the load the quicker
the nice value increases.
4. When the load average is above a given crital point (8.0 currently),
procs with priority > PBAD (approx = nice of 15) are swapped out,
and cannot return until the load drops to a more acceptable level
(5.0 currently).
This has worked out very well on our heavily loaded 11/70 -- allowing
interactive jobs to run at an effective higher priority than crunchers
(which, if they accumulate enought cpu time, only run when the cpu
would otherwise have been idle).
--peter gross
ucbvax!hplabs!hao!pag
seismo!hao!pag