From owner-freebsd-smp Thu Oct 3 07:17:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29361 for smp-outgoing; Thu, 3 Oct 1996 07:17:26 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA29351 for ; Thu, 3 Oct 1996 07:17:17 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id PAA26230; Thu, 3 Oct 1996 15:15:59 +0100 Date: Thu, 3 Oct 1996 15:15:59 +0100 (BST) From: Doug Rabson To: Peter Wemm cc: Chris Csanady , freebsd-smp@freebsd.org Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-Reply-To: <199610031239.UAA05805@spinner.DIALix.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Oct 1996, Peter Wemm wrote: > > At present, we have 32 run queues with 4 (8?) priority levels in each > queue. When the scheduler runs, it picks the first process off the top of > the highest priority queue. > > Something has to be done here since there seems to be no real way to bias > processes to attempt to give them preference for a single cpu to get some > advantage of the on-cpu cache. Otherwise, the processes seem to bounce > backwards and forwards from one cpu to the other and so on. > > I don't know an easy answer offhand.. > > If we maintain this strategy, perhaps we'd need to have one set of 32 run > queues for each cpu as well as the common one. The scheduler could look > in the per-cpu queue first and if there's a process available that's "near > enough" to the head of the "real" run queue then choose that. That starts > to get messy though, perhaps a simple list of "recently run processes" to > look in the run queues for may be enough. > > > I dont know.. perhaps I should just stay away from some stuff. :) > > Well, if anybody comes up with a better strategy that fits the kernel > without too much trauma (that's also understandable), it's worth hearing. 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. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426