Date: Fri, 04 Oct 1996 02:27:35 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: dg@Root.COM Cc: Doug Rabson <dfr@render.com>, freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) Message-ID: <199610031827.CAA06666@spinner.DIALix.COM> In-Reply-To: Your message of "Thu, 03 Oct 1996 07:24:07 MST." <199610031424.HAA12159@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >Why not use a byte in struct proc for the cpuid of the processor which > >most recently ran the process. If there is a choice of highest-priority > >processes, each cpu could choose a process which it has run before, > >otherwise just pick the highest priority process as normal. > > Right, if the CPU that it ran on last isn't available, but another one is, > you don't want to *not* run it just because of the processor affinity. > > -DG Oh yes, definately.. It's just a question of how much value to put on the cache contents and how much we're prepared to bias things. Suppose we had three runnable processes, it'd be a shame to have two cpu's running them in turn and none of them getting back to the same cpu until the other two have run on it. We recalculate the the process priorities about 10 times per second, right? If we have three processes at equal priority, and hence the same run queue. If we change the selection algorithm from "front of queue" to "if there is a process in this queue with the same cpu id, choose it, otherwise pick the front", then we could have the situation where both cpus could run two of the three processes for 10 quantums and the third would get none until the next reschedule caclulation. Perhaps there would need to be a limit on the number of times a process could jump to the head of it's run queue just because it was last on the cpu? (eg: a limit of between 3 to 5 quantums) I suspect the "ideal" parameters will depend on the per-machine configuration. A couple of pentiums with their small on-chip cache and a single shared large cache would probably place less value on the per-cpu cache than perhaps a pentium-pro system with 256K (or 512K) on-chip with no shared cache would. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610031827.CAA06666>