Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!julius.cs.uiuc.edu!rpi!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!csc.anu.edu.au!manuel!ccadfa!prolix!dac From: dac@prolix.ccadfa.oz.au (Andrew Clayton) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Single user OS schedulers (Was Re: How do we change the scheduler?) Message-ID: <18987305.ARN27dd@prolix.ccadfa.oz.au> Date: 28 Jan 91 13:21:41 GMT References: <1991Jan23.213736.28220@Neon.Stanford.EDU> <1991Jan24.152931.1325@NCoast.ORG><1991Jan25.073516.29644@Neon.Stanford.EDU><1 991Jan26.035750.11786@NCoast.ORG><1991Jan27.014242.2863@Neon.Stanford.EDU><189704d7.ARN27ab@prolix.ccadfa.oz.au> <1991Jan27.221142 Reply-To: ccadfa.cc.adfa.oz.au!prolix!dac@munnari.OZ.AU Followup-To: comp.sys.amiga.advocacy Organization: I'm not an Organization - I'm a person! Lines: 95 In article <1991Jan27.221142.20062@ncsuvx.ncsu.edu>, John Vestal And in article <1991Jan27.223145.18292@Neon.Stanford.EDU> (Evan J Torrie) There were basically the same rebuttals to my rebuttals: AC> Huh? The OS doesn't interfere with your DECISION to run multiple programs AC> at the same time. By default, spawned programs have a priority of zero AC> (0) thus they *share equitably* the CPU resource. (1) JV> I think the point here, is that I might want to let one program get a JV> higher percentage of the CPU. Not share equally, but get, say 65%, and JV> let the rest of the stuff have the other 35%. But I want to be JV> garrentteed(sp) that the other processes get the 35%. Currently in JV> AmigaDOS, you can't do that. Once a process has a higher priority, all JV> bets are off as to how much CPU other lower tasks get. They get the JV> "leftovers". (2) ET> It's my contention that the OS should poke its nose into this, though, by ET> PREFERRING interactive tasks over compute intensive. Even Unix does this, ET> by aging tasks based on its recent CPU usage, and I would argue that on a ET> single user OS, this preference for interactive tasks should be even more ET> pronounced. You both want the operating system to stick it's nose in, or at least do some cogitation on what SORT of task gets timeslices. No dice. Going on my knowledge of mainframe schedulers leads me to believe that task switching based on what the USER want's to achieve is ALWAYS better than any generalised 'guessing' algorithm in the OS. You prefer the OS to do some thinking for you, but that algorithm has to be worked out, and no *generalised* one will meet everyone (or even anyones!) personal preferences. Leaving out all the 'guessing', and having the OS work purely on a priority basis, makes for a more efficient scheduler. If you *want* to you can change the way your machine reacts to different tasks running. It's more a religious issue, I guess. Some people say 'don't play with the scheduler' and others look on aghast stating that they aren't using resources effectively if they DON'T change scheduler parameters to suit job mix. The two camps are prolly doomed to eternal bickering. :-). The bottom line is; AmigaDos is priority based, and I like it like that. I win. :-) :-) :-). AC> Duh! Lets make the OS democratic! :-). *YOU*, all by your lonesome, get AC> to make the decision if you want processes to have priority. Most people AC> don't mess with the scheduler. It's best left alone. (1) JV> The best bet, I think, is to have something that says, I will age JV> processes if you users wants to, but if I need realtime response, then I JV> won't age other processes. The OS that I use on my computer has two JV> variables for the democracy. (2) ET> The problem is, though, that the decision to give a process a particular ET> priority is a static decision. What do you do about processes, which ET> spend most of their time being interactive (so you give them a bump up in ET> priority), but then, every now and again go into a compute intensive loop. You are both on the same wavelength -- the decision, however it goes, is currently a user one. Wasting (and I do mean WASTING) CPU resource by having the CPU determine odd -airy fairy- parameters (Base Quantums, aging rates, express priority) is quite obviously resource that is constantly consumed, and never recovered. Neither your ray tracing program, or your program that asks users questions and then calculates pi to several billion decimal places will get the BENEFIT of this once_every_20ms_scheduler code. It's going to reduce performance, and that, I'm afraid, is *my* criterion for 'badbadbad'. AC> either up or down in priority has a HUGE effect on the other tasks. JV> It shouldn't, in my opinion, have that HUGE of a difference in tasks JV> unless you set the process's priorities so they are a long way apart. I JV> realy shouldn't be able to tell that much difference between priorities JV> that differ by one. I do agree with you, John, that SMALL shifts in the value of priority making HUGE differences to performance of a given set of tasks, is somewhat clumsy. Smoothing out the priority takes CPU resource. Bad move. Lets leave it alone, eh! ET> (P.S. this thread is rapidly getting stale, so it will probably cease to ET> exist in the near future) Ah, the joys of people wanting to complain forever. Where's -MB- when you need him? [Joke, joke, honest]. Dac _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ ccadfa.cc.adfa.oz.au!prolix!dac . . I am. -------- I cannot send or receive email. Not to anyone at all. Not even you.