From owner-freebsd-smp  Thu Oct  3 11:28:20 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA13579
          for smp-outgoing; Thu, 3 Oct 1996 11:28:20 -0700 (PDT)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA13555
          for <freebsd-smp@freebsd.org>; Thu, 3 Oct 1996 11:28:15 -0700 (PDT)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id CAA06666;
          Fri, 4 Oct 1996 02:27:36 +0800 (WST)
Message-Id: <199610031827.CAA06666@spinner.DIALix.COM>
X-Mailer: exmh version 1.6.7 5/3/96
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 . . 
 ) 
In-reply-to: Your message of "Thu, 03 Oct 1996 07:24:07 MST."
             <199610031424.HAA12159@root.com> 
Date: Fri, 04 Oct 1996 02:27:35 +0800
From: Peter Wemm <peter@spinner.dialix.com>
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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