Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!purdue!decwrl!shelby!polya!gilham From: gilham@polya.Stanford.EDU (Fred Gilham) Newsgroups: comp.sys.amiga Subject: Re: AmigaDOS scheduling Message-ID: <9300@polya.Stanford.EDU> Date: 19 May 89 05:24:32 GMT References: <17148@usc.edu> <24279@agate.BERKELEY.EDU> <18268@cup.portal.com> <17183@usc.edu> <21814@srcsip.UUCP> <18037@cisunx.UUCP> <1861@internal.Apple.COM> <761@boing.UUCP> <216@doctor.Tymnet.COM> Sender: Fred Gilham Reply-To: gilham@polya.Stanford.EDU (Fred Gilham) Organization: Stanford University Lines: 20 In article <216@doctor.Tymnet.COM> jms@doctor.Tymnet.COM (Joe Smith) writes: > >The current priority scheme means that a ray-tracing program at priority -6 >will not get any runtime if there is another compute-bound program running at >priority -5 or higher. I would like to see a schedular that would allow me to >declare that this compute-bound program is to get 1/3 of the background cycles >and that compute-bound program is to get 2/3 of the background cycles. > There are all kinds of schedulers out there. I happen to like the one where the scheduler can migrate tasks between priority levels, so that if one's a cpu hog it gets migrated back, but if it doesn't get to run for a while because there's another cpu hog around, it gets migrated up. This migration occurs within limits. You can start a program at a given level and only let it migrate so many levels back (so that your interactive programs never migrate back to "background" levels). Of course, a program never migrates any farther forward than its base priority. I think this has the advantage of adapting to changing conditions, besides which it is pretty simple to implement. -Fred Gilham