🚀 go-pugleaf

In article <41it45$357@usenet.ucs.indiana.edu>,
scott goehring <sgoehrin@copper.ucs.indiana.edu> wrote:
> >The overhead has to be paid one way or the other, whether it's by explict
> >delay calls in the application or clock interrupts.

> as i wrote elsewhere, neither of these is _required_.  you don't have
> to require releases or have clock interrupts.  you only need this if
> you are interested in keeping average wait time low.

If you want multitasking at all, you need one or the other.

> if this is not a
> design goal, you can dispense with this.

Multitasking is indeed not always a design goal.

> >For the job to enter the run queue something must have preempted the job
> >currently running.

> on at least one super i've seen the run queue is managed entirely by
> the front-end processor, which has transfer access to the super's
> memory.  so the front-end can load the entire job, then order the
> super to suspend the running job and (re)start the new job.  even
> swapping can be done on such systems by the front end system.  of
> course, in this case the super is really a slave coprocessor to the
> front-end. :)

In which case the O/S is running on the front end. Doesn't change my
point at all.

> >Even on my Amiga the "preemption overhead" is too small to measure.

> but it is there. :)

Except for the specific case of a supercomputer where CPU time costs more
than uranium, preemption overhead is low enough to ignore. And in the case
of a supercomputer you're not running a multitasking O/S on the super at all.

If you're multitasking, preemption is cheaper.
-- 
Peter da Silva    (NIC: PJD2)      `-_-'             1601 Industrial Boulevard
Bailey Network Management           'U`             Sugar Land, TX  77487-5013
+1 713 274 5180         "Har du kramat din varg idag?"                     USA
Bailey pays for my technical expertise.        My opinions probably scare them