Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga,comp.sys.mac
Subject: Re: Multitasking: Amiga vs. Unix, and apple comments
Message-ID: <4853@jade.BERKELEY.EDU>
Date: Sat, 22-Aug-87 18:52:49 EDT
Article-I.D.: jade.4853
Posted: Sat Aug 22 18:52:49 1987
Date-Received: Sun, 23-Aug-87 22:12:04 EDT
References: <6565@eddie.MIT.EDU> <2742@hoptoad.uucp>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 69
Xref: mnetor comp.sys.amiga:7690 comp.sys.mac:5892

In article <56@stb.UUCP> michael@.UUCP (Michael) writes:
<#2. Demand paging.
<This is good only for one thing: Letting a large program run on a small machine.

No, it's also good for having a set of runnable programs whose total
size is larger than real memory. The net result of this is better
performance than either a swapping system or a system without that
feature under those conditions. Of course, you get slightly worse
performance if your load isn't that high.

<Personally, I think this could be improved by giving more priority (read:
<resources) to an interactive task even when its not running. Unix is
<notoriously bad with interactive tasks--esp. on swapping systems where as
<soon as it does the read(), it gets swapped.

Time for "History of Unix." Unix was originally rewritten in C for a
system with few users on at any give time. It had a nice, simple
scheduler to go with that. This is the scheduler that was in v6, v7,
PWB 1.0, PWB 2.0, SysIII, SysV (throught at least r2), and BSD through
2.7 and 4.1. As you pointed out, interactive tasks suffer badly in the
presence of background CPU hogs.

Lots of people know this. George Goble at Purdue was one of them. He
rewrote that scheduler and installed it in his v7 systems. That's the
scheduler that is in 4.2, 4.3, 2.8, 2.9 and 2.10 BSD.

It doesn't really go far enough. If the number of CPU hogs is much
greater than the number of interactive jobs (say, 50% more) then the
interactive jobs start suffering again. There is a single number (4)
in this scheduler that can be changed (make it 8) to fix the problem.
But that just pushes the limit up, and makes all those background jobs
suffer. Also, it's not an easily tunable number; it's a magic number
in kern_clock.c

There are people experimenting with schedulers that track different
types of resources (disk, tty, memory, cpu, etc) and computes a
weighted average, where the weights are settable by a system call.
Hopefully, this will wind up in 4.4, if not SysVr4.

<#3. Two tasks competing for time.
<<Sigh>. Ok, so no scheme is perfect. Yes, with two tasks trying to run
<at the same time, it will be twice as slow.

Key words "trying to run." Fortunately, most tasks don't try to run
all the time; some of them very little of the time. You only get
"twice as slow" if you've got two cpu hogs. Normal tasks (like 9 of
the 10 I've got running) spend a fair amount of time waiting for disk,
or the user, or whatever.

<The trick is to give the more interactive one higher priority (unix does),
<and give higher priority ones more resources (unix does NOT).

Well, we had a v6 system with what we called the "walk on water" hack
(from that very same George Goble). If your nice was better than -5,
any requests for disk IO went straight to the head of the queue.

This eventually degenerates into first-come-first-served disk scheduling,
which defeats the purpose of disk scheduling. While it's fairly
obvious that user-settable priorities will do a good job (maybe not
great, but good) of CPU scheduling for a single-user system, it's not
at all clear that there is any such disk scheduling strategy. I'd like
to know what AmigaDOS is doing, though.

	<mike
--
Round about, round about, in a fair ring-a.		Mike Meyer
Thus we dance, thus we dance, and thus we sing-a.	mwm@berkeley.edu
Trip and go, to and fro, over this green-a.		ucbvax!mwm
All about, in and out, over this green-a.		mwm@ucbjade.BITNET