Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!steinmetz!vdsvax!barnett From: barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) Newsgroups: comp.sys.amiga,comp.sys.mac Subject: Re: Defense of multi-tasking response Message-ID: <2330@vdsvax.steinmetz.UUCP> Date: Fri, 21-Aug-87 11:38:13 EDT Article-I.D.: vdsvax.2330 Posted: Fri Aug 21 11:38:13 1987 Date-Received: Sun, 23-Aug-87 03:38:01 EDT References: <407@cc5.bbn.com.BBN.COM> Reply-To: barnett@steinmetz.UUCP (Bruce G Barnett) Organization: General Electric CRD, Schenectady, NY Lines: 50 Xref: mnetor comp.sys.amiga:7633 comp.sys.mac:5845 In article <407@cc5.bbn.com.BBN.COM> denbeste@cc5.bbn.com.BBN.COM (Steven Den Beste) writes: |All of this assumes that the user sets up the priorities correctly. On some |systems it is done automatically by making any process which comes off an I/O |queue be slightly higher priority for a couple of slices. Here we get into the |black magic of scheduling algorithms, and risk losing our souls to some dark |anti-deity. At the risk of my soul :-), here is what I understand of UN*X's algorithm. On UN*X System V, the system clock ticks 50-100 times a second. For each tick: If the current running job isn't blocked - it doesn't reschedule. If is does block ( waiting for I/O), the next job in the ready-to-run queue starts off. The current job gets a counter incremented, indicating CPU usage, or number of slices the task has used for the last 8 seconds. The priority is based on priority = CPU USAGE / 2 + base-level-priority Once a second: The CPU USAGE for each job is divided by two. It also re-computes the priorities of the tasks, and reschedules them if necessary. So it should be obvious that: Interactive tasks get high priority. CPU-bound tasks are scheduled by a round-robin mechanism. If a job gets 100% of the CPU ( i.e. 100 ticks) for 1 second, and is idle for eight seconds, the CPU usage after the decaying period drops to 0 ( divide 100 by 2, eight times) The scheduler penalizes CPU-bound jobs in favor of I/O intensive jobs. This provides `reasonable' sharing of resources, without the user writing any special `hooks' into the code. Also the user rarely has to change priorities. -- Bruce G. Barnett