Date: Wed, 26 Jul 95 19:47:49 METDST From: Marino.Ladavac@aut.alcatel.at To: davidg@root.com Cc: freebsd-hackers@freebsd.org Subject: Scheduling Algorithms (was: Re: panic in brelse() ... ) Message-ID: <9507261747.AA02751@atuhc16.aut.alcatel.at> In-Reply-To: <199507260850.BAA27035@corbin.Root.COM>; from "David Greenman" at Jul 26, 95 1:50 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ Mr. Matt Dillon explains his scheduling algorithm which he intends to test ] Matt, if I recollect correctly, you submitted this to the Linux camp, and I remember people using it. What were their comments? (please excuse me for being on first name basis :) [ Mr. David Greenman responds: ] > We've messed with the scheduling algorithm quite a bit since the original > one in 4.4BSD, and I think have made substantial improvements. Our main > concern was that compute-bound processes must execute in a lower priority queue > and there needs to be some form of backward inheritence of CPU consumption/ > priority. Without this, people doing compiles (or other compute-intensive > things) will quickly bring the system to it's knees. In the old model, CPU > priorities were evaluated once per second. This is fine for slow computers that > take a couple of minutes to compile your average C file, but on fast machines > that can do it in 1-2 seconds, we found that the compile job was always in the > foreground - making the system appear very sluggish to interactive users. I'd > like to here more about how your algorithm works in real-world situations and > especially how it functions across the spectrum of system loading. Maybe I shouldn't comment on this, as I am not familiar with the actual implementation, but Amiga had an interesting scheme of linearly increasing dispatch priorities, which were incremented by process priority. I.e., it took very few slices for a high priority process to be the one with the highest dispatch priority, but even the low priority processes did get executed. CPU consumption can be fed back with time slice consumption. Arithmetic can be replaced with run queue shifts. Sounds SysV-ish, eh? Was just a thought. Any obvious flaws there? /Alby. > -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507261747.AA02751>