Date: Wed, 30 Mar 2005 08:00:51 -0500 From: David Schultz <das@FreeBSD.ORG> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: bde@FreeBSD.ORG Subject: Re: Fwd: 5-STABLE kernel build with icc broken Message-ID: <20050330130051.GA4416@VARK.MIT.EDU> In-Reply-To: <20050330080113.GA71384@cirb503493.alcatel.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050330130051.GA4416>