From owner-freebsd-smp Thu Oct 3 14:01:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA23095 for smp-outgoing; Thu, 3 Oct 1996 14:01:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA23084 for ; Thu, 3 Oct 1996 14:01:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA06723; Thu, 3 Oct 1996 13:58:58 -0700 From: Terry Lambert Message-Id: <199610032058.NAA06723@phaeton.artisoft.com> Subject: Re: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . To: peter@spinner.dialix.com (Peter Wemm) Date: Thu, 3 Oct 1996 13:58:58 -0700 (MST) Cc: dg@Root.COM, dfr@render.com, freebsd-smp@FreeBSD.org In-Reply-To: <199610031827.CAA06666@spinner.DIALix.COM> from "Peter Wemm" at Oct 4, 96 02:27:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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. This is a policy decision. Policy should be controllable by the system administrator. The trade between losing cache vs. losing CPU cycles really depnds on how compute intensive the code which will be running is going to be. The best thing that you could do would be to collect meaningful metrics and implement a very simple policy that reacts to them, leaving a more complex policy for when an administrator purposes the machine. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.