Messages in this thread |  | | From | "James R. Leu" <> | Subject | Re: Interesting multitasking bug. | Date | Tue, 28 Jan 1997 09:36:26 -0600 (CST) |
| |
...
> > Any idea what causes this? This is a P133, PCI video, 32MB RAM. >
This just my uneducated guess. Because of the code in goodness() (sched.c) the current process is favored when calculating the goodness values. I have played with this quite a bit. I have tried making all processes equal, and varing degrees of penalizing the current process. On my servers here (fairly heavy use) they always perform better when I penalize the current process.
My theory as to why it works. A CPU intensive process running on a lightly loaded machine will eat up its time slices quickly (I beleive each process can have three time slices before the kernel will reschedule), thus it is penalized when process are rescheduled. The same process on a heavly loaded machine will not have a chance to use up its time slices because the process queue is so long. So when it comes time to reschedule it will most likely "win" (ie become the next scheduled process). Then then process will continue to "win" because it is favored by by the goodness() routine, and because it doesn't use up all of its time slices. This contiuatual winning of one process causes fairly long "lags".
Try this on your machine and let me know if it helps your situation. Find this area of code in linux/kernel/sched.c
/* .. and a slight advantage to the current process */ if (p == prev) weight += 1;
And change: weight += 1; to: weight -= 1;
Recompile, run a few test and please tell me what the effect is.
Remember these are all my uneducated guesses. (some kernel guru is probably gonna smite me for my attempt)
James -- James R. Leu Network Administrator CORE Digital Communication Services jleu@coredcs.com
|  |