Larry Allen <lwa@mit-mrclean.ARPA> (11/17/84)
One of our users noticed that processes which accumulated a lot of CPU
time under 4.2 bsd (for example, a Emacs which had been running on the
same terminal for 3 days) would suddenly and seemingly arbitrarily get
reniced. After a little bit of tracking, I found the following code in
/sys/sys/kern_clock.c/softclock():
/*
* Check to see if process has accumulated
* more than 10 minutes of user time. If so
* reduce priority to give others a chance.
*/
if (p->p_uid && p->p_nice == NZERO &&
u.u_ru.ru_utime.tv_sec > 10 * 60) {
p->p_nice = NZERO+4;
(void) setpri(p);
p->p_pri = p->p_usrpri;
}
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 AllenMike Muuss <mike@BRL-TGR.ARPA> (11/18/84)
The renice to 4 after 10 minutes of CPU time could be eliminated with no consequences other than the obvious. However, the short- term scheduling effects are not enough to prevent long-running CPU or I/O intensive processes started at nice 0 from seriously impacting interactive performance. Something else is needed. I did a really snazzy scheduler for our V6 systems, and some day if I ever get the time to work on it, I hope to incorporate some of those ideas into our 4.2 kernel as well. Best, -Mike Muuss
wls@astrovax.UUCP (William L. Sebok) (11/19/84)
> 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