bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/25/87)
> Ideally the system would have a provision for a special task bit > of "INTERACTIVE". A interactive task would receive the processor before > other tasks of the same true priority, *BUT* if for n consecutive slices it > hogged the processor, the other tasks could get some slices. My canidate for this bit would be in Intuition's window and screen structures. A strange place until you consider that Intuition knows best about ACTIVE windows, and adding the bit and tacking on a pointer would be %100 backwards compatible to V1.0, V1.1 & V1.2. For obvious reasons there is only one active interactive task at a time. |\ /| . Ack! (NAK, EOT, SOH) {O o} . ( " ) bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce U I'd like to rotate the guy that invented the BPTR! This message VOID in states where it is illegal to flame oneself.
perry@atux01.UUCP (P. Kivolowitz) (06/26/87)
In article <8706251111.AA08860@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > > Ideally the system would have a provision for a special task bit > > of "INTERACTIVE". A interactive task would receive the processor before > My canidate for this bit would be in Intuition's window and screen > structures. A strange place until you consider that Intuition knows 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: The more you execute the lower your priority The lower your priority the less you execute The less you execute the more your priority The more your priority the more you execute The more you execute the lower your priority (and loop) Interactive processes spend most of their time interacting and therefore naturally float at the highest range of priorities available to user processes. Simply adding bits is not the way to go about modifying one's scheduler. I personally think that the Amiga's exec has too simple a scheduler and might benefit from being completely rethought. As usual, simple problems do not have simple answers. Perry S. Kivolowitz ASDG Incorporated (201) 563-0529
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/03/87)
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