Automatic re-nicing of processes under 4.2 bsd

[William L. Sebok]

> What this does is to reduce the nice of any process
> 1) which is not be run by the superuser
> 2) whose nice is 0
> 3) which has accumulated more that 10 minutes of CPU time in its lifetime
> The nice of such a process is arbitrarily set to 4.
> 
> This whole strategy seems totally bogus to me - it penalizes long-lived
> programs even if they're not CPU bound.  Moreover, it seems unnecessary -
> there is already code in /sys/sys/kern_synch.c/schedcpu() (called by
> timeout once a second) to reduce the scheduling priority of CPU-bound
> processes and increase the scheduling priority of I/O-bound processes.
> 
> Can this code be eliminated?  Would there be any unexpected side-effects
> I haven't thought of?
> 					-Larry Allen

In fact here it has been changed to set the nice to 8.  You must not have
a lot of people running background numerical calculations. There are usually
three or four of those always running here. This code is there to control long
running background processes which the user is anti-social enough not to start
at low priority.  The code in /sys/sys/kern_synch.c/schedcpu() is not nearly
enough.  The algorithim in the clock routine has been changed here to set a
process's niceness to 8 if

 1) it is not run by the superuser
 2) whose nice is between 0 and 5
 3) who have accumulated more thatn 10 min CPU in its lifetime.

 The reason for 2) is
   a) processes running nice 6 or 7 remain untouched.  This provides a bonus
   to users nice enough to start their jobs off niced.
   b) processes with negative niceness are untouched.  This provides a method
   with which some privileged users running interactive image processing
   applications can have there programs stay at reasonable priority.

The reason I changed the penalty niceness from 4 to 8 is that this floor
becomes a ceiling and the computer is soon filled with processes running at
that niceness.  I determined that interactive response was still slowed with
no nice 0 programs running if there were many nice 4 process running.

Ideally this whole mechanism should be replaced or supplemented by one which
takes into account the time since the terminal last blocked for input. This
would allow keeping the background jobs under control while still having
mercy on long-lived emacs processes (or image processing programs).  However I
have not been ambitious enough yet to try to figure out how to do it or indeed
if it can be done efficiently.  Any takers?
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls