Date: Wed, 9 Jan 2002 19:00:59 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dan Eischen <eischen@vigrid.com> Cc: <arch@FreeBSD.ORG> Subject: Re: Getcontext resolution? Message-ID: <20020109184836.A7595-100000@gamplex.bde.org> In-Reply-To: <3C3ADC3B.F75D2669@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jan 2002, Dan Eischen wrote: > Bruce Evans wrote: > > > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > #if 0 > > > fnstcw MC_FP_CW_OFFSET(%edx) /* save control word */ > > > movl $UC_MC_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext valid, no FP */ > > > #else > > > fnsave MC_FP_REGS_OFFSET(%edx) /* save FP regs */ > > > movl $MC_FP_VALID, MC_FLAGS_OFFSET(%edx) /* mcontext and FP valid */ > > > #endif > > > > Even the fnstcw will cause a trap the the kernel on i386's if the state > > isn't already in the FPU, so little or negative might be gained relative > > to a syscall that can sometimes just copy the state. > > But it will only occur the first time and not on subsequent context > switches, right? Unless the process gets swapped out and then resumed > again by the kernel. In that case, you are saying that the kernel > doesn't restore the FPU state when the process gets resumed? Every time per kernel context switch (including ones to ithreads in -current). On every kernel context switch, the kernel saves the FPU state in the pcb (if it is in the FPU) and sets CR0_TS in cr0 (if it isn't already set) so that the next FPU instruction in the process traps to the kernel for restoring the FPU state from the pcb. The kernel never restores the FPU state at context switch time since it has no idea if the state will be used again and guesses that it will not be. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020109184836.A7595-100000>