From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 30 13:00:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECEFA16A4CE; Wed, 30 Mar 2005 13:00:58 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD2F43D1F; Wed, 30 Mar 2005 13:00:58 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j2UD0qj6004486; Wed, 30 Mar 2005 08:00:52 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j2UD0pvt004485; Wed, 30 Mar 2005 08:00:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 30 Mar 2005 08:00:51 -0500 From: David Schultz To: Peter Jeremy Message-ID: <20050330130051.GA4416@VARK.MIT.EDU> Mail-Followup-To: Peter Jeremy , jason henson , hackers@FreeBSD.ORG, bde@FreeBSD.ORG References: <423C15C5.6040902@fsn.hu> <20050327133059.3d68a78c@Magellan.Leidinger.net> <20050327134044.GM78512@silverwraith.com> <20050327162839.2fafa6aa@Magellan.Leidinger.net> <5bbfe7d405032823144fc1af7b@mail.gmail.com> <5bbfe7d405032823232103d537@mail.gmail.com> <20050329111107.GD69824@cirb503493.alcatel.com.au> <424A23A8.5040109@ec.rr.com> <20050330080113.GA71384@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050330080113.GA71384@cirb503493.alcatel.com.au> cc: hackers@FreeBSD.ORG cc: jason henson cc: bde@FreeBSD.ORG Subject: Re: Fwd: 5-STABLE kernel build with icc broken X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2005 13:00:59 -0000 On Wed, Mar 30, 2005, Peter Jeremy wrote: > On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote: > >Later in that thread they discuss skipping the restore state to make > >things faster. The minimum buffer size they say this will be good for > >is between 2-4k. Does this make sense, or am I showing my ignorance? > > > >http://leaf.dragonflybsd.org/mailarchive/kernel/2004-04/msg00264.html > > Yes. There are a variety of options for saving/restoring FPU state: > a) save FPU state on kernel entry > b) save FPU state on a context switch (or if the kernel wants the FPU) > c) only save FPU state if a different process (or the kernel) wants the FPU > 1) restore FPU on kernel exit > 2) restore FPU state if a process wants the FPU. > > a and 1 are the most obvious - that's the way the integer registers are > handled. > > I thought FreeBSD used to be c2 but it seems it has been changed to b2 > since I looked last. > > Based on the mail above, it looks like Dfly was changed from 1 to 2 > (I'm not sure if it's 'a' or 'c' on save). > > On the i386 (and probably most other CPUs), you can place the FPU into > am "unavailable" state. This means that any attempt to use it will > trigger a trap. The kernel will then restore FPU state and return. > On a normal system call, if the FPU hasn't been used, the kernel will > see that it's still in an "unavailable" state and can avoid saving the > state. (On an i386, "unavailable" state is achieved by either setting > CR0_TS or CR0_EM). This means you avoid having to always restore FPU > state at the expense of an additional trap if the process actually > uses the FPU. This is basically what FreeBSD does on i386 and amd64. (As a disclaimer, I haven't read the code very carefully, so I might be missing some of the details.) Upon taking a trap for a process that has never used the FPU before, we save the FPU state for the last process to use the FPU, then load a fresh FPU state. On subsequent context switches, the FPU state for processes that have already used the FPU gets loaded before entering user mode, I think. I haven't studied the code in enough detail to know what happens for SMP, where a process could be scheduled on a different processor before its FPU state is saved on the first processor.