muller@sdcc3.UUCP (Keith Muller) (02/21/85)
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