From owner-freebsd-hackers  Tue Apr 25 18:24:13 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id SAA28312
          for hackers-outgoing; Tue, 25 Apr 1995 18:24:13 -0700
Received: from seagull.rtd.com (root@Seagull.rtd.com [198.102.68.2])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA28300
          for <freebsd-hackers@freefall.cdrom.com>; Tue, 25 Apr 1995 18:23:59 -0700
Received: (from dgy@localhost) by seagull.rtd.com (8.6.9/8.6.9.1) id SAA20990 for freebsd-hackers@freefall.cdrom.com; Tue, 25 Apr 1995 18:23:46 -0700
From: Don Yuniskis <dgy@seagull.rtd.com>
Message-Id: <199504260123.SAA20990@seagull.rtd.com>
Subject: Re: benchmark hell.. (Really context switch & FPU)
To: freebsd-hackers@freefall.cdrom.com (FreeBSD hackers)
Date: Tue, 25 Apr 1995 18:23:41 -0700 (MST)
In-Reply-To: <199504260012.RAA09198@ref.tfs.com> from "Poul-Henning Kamp" at Apr 25, 95 05:12:30 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 839       
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> Well, you guys, when can we see the code ??
> 
> > I didn't explain.  Sorry!  I assumed we would want to do
> > lazy FP context save/restore.  Once you do that, further
> > refinements don't buy you very much.  If you reread what I
> > wrote _in this context_, may be it will make more sense.
> > 
> > > o       The FPU has a "last used by" state variable
> > > o       When the first FPU using process is run, this variable is
> > >         set to its PID.
> > Okay.

I've implemented this in a couple of real-time OS's and it really is
a big win -- especially if the FPU can execute in parallel with the 
CPU's execution unit (some FPU's can't) and you invest the time hooking
the FPU traps to do belated switches *only on demand*.  It does have
some impact on real-time determinism ... but I doubt that would
be a real issue in FBSD.