Load control system posted to net.sources (repost)

[Keith Muller]

The most recent version of the load control system has been posted to
net.sources in eight(8) shar files. The load control system has been
in use at UCSD for about 18 months. The main purpose of load control
is to prevent unix systems running 4.2 BSD from thrashing and decreasing
system throughput. This is done by limiting the load average of the system
by blocking certain types of processes that are not interactive and are
major resource users. This limit keeps the system from spending large
amounts of the available cpu resources on wasteful tasks like paging
and excessive context switches. By preventing large swings of the load average,
the system never decays to point where useful work (user processes) no longer
gets executed.  Load control in effect "clips" load peaks and fills in the
valleys with these delayed processes.

Load control of course will not make individual tasks run any faster but
the increase of system throughput on overloaded systems is dramatic. Tasks
complete in much less real time and the response of the system to interactive 
jobs like editors remain acceptable. This has proven to be much superior than
adjusting the priority of tasks in most cases. Long running tasks should still
be "niced" to keep them from saturating the system for long periods of time.
But for most jobs (jobs using 30 cpu minutes or less) (95% of the jobs on my
machines), load control is all that is needed.

Load control has run 24 hours a day for 18 months on 5 machines (vaxes and
pyramids) without an error. These machines serve about 6500 (six thousand
five hundred not a typo) users mostly students. These students never think
twice about running as many jobs in the backround as they feel they need.
Before load control the systems would easily reach load averages of 45
(once i saw it over 100) and nothing ever seemed to get done. After load control
the load never rises very much above the set limit (usually about 10.0), and all
the work gets done in much less wall time (try running vi with a load of
40 and see how much gets done!).

The load control system does not require any kernel modifications and will
run without modification on vaxes, suns, and pyramids (4.2 BSD only). The
overhead cost of running load control uses about 1 minute of cpu per day
(or less than one tenth of 1 percent of the machine). The code is extensively
commented and has been performance tuned over several months. (NO trojan
horses either).

One interesting use I have found for load control is using it to measure the
real timesharing performance of various types of machines running 4.2 unix
(not just the speed of a single process "benchmark").  With minor amounts of
hacking (not supplied and not recommended for production systems use) load
control can measure how many jobs can be run in a given amount of real time.
(The pyramid 90x's beat everything here, showing about four times the
throughput of a similar size 11/780 for the same job mix of cc's and vi's).

	Keith Muller
	University Of California, San Diego
	ucbvax!sdcsvax!muller