Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: Re: Note on Interactive task priority implementation
Message-ID: <4232@jade.BERKELEY.EDU>
Date: Thu, 2-Jul-87 21:50:19 EDT
Article-I.D.: jade.4232
Posted: Thu Jul  2 21:50:19 1987
Date-Received: Sat, 4-Jul-87 12:58:59 EDT
References: <8706251111.AA08860@cogsci.berkeley.edu> <475@atux01.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Organization: Missionaria Phonibalonica
Lines: 64

In article <475@atux01.UUCP> perry@atux01.UUCP (P. Kivolowitz) writes:
<In article <8706251111.AA08860@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
<This seems kludgey. The way the Un*x operating system handles this is
<elegant in that the desired effect (keeping interactive processes  at
<interactive priorities) is a by product of the Un*x scheduling  algo-
<rithm. In short:

Elegant, maybe. It also didn't work. Put any significant load in the
background on a Unix box, and watch interactive response vanish. This
is why BSD has the hack of "if you've got more than N minutes of CPU,
change nice from 0 to 4." It works about like you'd expect such a hack
to work; it makes the amount of background work you can put on the
system slightly larger. Changing the 4 to an 8 (can you say "adb -k
/vmunix /dev/kmem"? I knew you could) pushes it even further back.
It also means that long-running interactive processes (like GNU emacs)
get hit by that renice. Not good.

The Multics version of that algorithm should work even better:
	The more you of the CPU you get, the lower your priority.
	Do IO from a tty, your priority goes back to normal.

The difference is that your priority goes back up if you're *really*
an interactive processes, not just because you got pushed way down the
priority list.

Changing this to fit into the Amiga fixed-priority scheduler would
look something like: If we know it's not interactive, downgrade its
priority a bit. If it goes interactive again, put it's priority back
where it came from. The "kludgy" suggestion was:

<> > Ideally the system would have a provision for a special task bit
<> > of "INTERACTIVE".  A interactive task would receive the processor before

This sounds like almost the same thing, except you call "normal" the
non-interactive state, instead of the interactive state.

<Simply adding bits is not the way to go about modifying one's scheduler.

Depends on the goal. Likewise, simply copying a much-used scheduling
algorithm is not the way to go about modifying one's scheduler,
either. Some thought beforehand usually helps.

<I personally think that the Amiga's exec has too simple a scheduler  and
<might benefit from being completely rethought.

Possibly. I think that the scheduler is right for most people.
Trouble is, it's getting used a lot by hackers, who tend to overdrive
it. Rethinking it in light of that may be a good idea. But can it be
done without raising the scheduling overhead?

<As usual, simple problems do not have simple answers.

Correct. The question is whether the problem can be adequately solved
by minor changes to the simple system in place now, or do we need a
major rewrite? Minor changes are easy to install & test. A major
rewrite might not be.

	<mike

--
The handbrake penetrates your thigh.			Mike Meyer
A tear of petrol is in your eye.			mwm@berkeley.edu
Quick, let's make love before we die.			ucbvax!mwm
On warm leatherette.					mwm@ucbjade.BITNET