Mark Crispin <MRC@SU-SCORE.ARPA> (11/20/84)
I'm a bit bewildered as to why this code should be necessary.
Computational processes, especially those with small memory usage,
should have little or no impact on the system except to other
computational processes. An operating system typically always has
such a process running; it's called the null job and often does
such useful tasks as counting to infinity.
Isn't Unix's scheduler smart enough to do this? I thought it
had been rewritten since the toy scheduler which existed in PDP-11
days?
-------scottha@azure.UUCP (Scott Hankerson) (12/05/84)
In article <5937@brl-tgr.ARPA> Mark Crispin <MRC@SU-SCORE.ARPA> writes: > > I'm a bit bewildered as to why this code should be necessary. >Computational processes, especially those with small memory usage, >should have little or no impact on the system except to other >computational processes. An operating system typically always has >such a process running; it's called the null job and often does >such useful tasks as counting to infinity. > > Isn't Unix's scheduler smart enough to do this? I thought it >had been rewritten since the toy scheduler which existed in PDP-11 >days? >------- You don't really want a null process to be scheduled at the same priority as your own process do you? Generally such processes are to be scheduled at very low priorities so that they are only continued when nothing else is running.
MRC@SU-SCORE.ARPA (12/09/84)
Scott Hankerson misunderstands my point. My arguement is that while a null process shouldn't be run if some other process wants to run, this should be more a general artifact of the scheduler, to treate CPU-bound processes differently from interactive processes by analysis of the process' past behavior. Many operating systems have sliding scales of priority and runtime quanta based on how interactive the process appears to be, whether it has voluntarily blocked or ran out of quanta, etc. -------