4.2bsd kernel auto-nicing, scheduling

[Boyd Roberts]

    In article <1014 at brl-smoke.ARPA> speck at vlsi.caltech.edu writes:
    >
    >    When I have to kill infinite-looping processes, I usually find
    >them at nice 0, while much more deserving processes are at nice 4,
    >getting nowhere...
    >
    >	if (uid != 0 && nice == NZERO && utime > 10*60)
    >		nice = NZERO+4;
    >
    >Only processes doing "real work" are penalized.  Runaway sendmail's
    >and syslog's go unbridled, since they are system overhead; likewise
    >page-thrashers and processes looping on EOF go un-niced, since these
    >use only system time, no user time (or nearly so).  Processes already
    >at nice 1 are left alone, so the malicious user can get an advantage
    >over the "real work" jobs at nice 4 (and magnify that advantage simply
    >by starting 20 infinite-loop jobs at nice 20, as one user demonstrated;
    >the load average was so high that the nice 4 job got no runtime).

It's good to see the "hack it till it works" approach is alive and well.
Given that the Berkeley paging code was written that way, it must be right.

We've also got some really keen heuristics:

    "real work" == large user time

So, from them we can make a few rash generalisations.  With these we can
code up some unworkable mess.

Some fairly viable work has been done on SHARE scheduling on UNIX
in Australia.  You should check it out.  It actually uses some
algorithms, and was even designed.

    "Don't diddle the code.  Choose a better algorithm."


Boyd Roberts

+++
+   ..!mcvax!ukc!inset!boyd
+   boyd at inset.co.uk
+   boyd at basser.oz
+
+++ "Isn't that kind of severe?"