Date: Tue, 08 Jan 2002 06:47:07 -0500 From: Dan Eischen <eischen@vigrid.com> To: Bruce Evans <bde@zeta.org.au> Cc: arch@FreeBSD.ORG Subject: Re: Getcontext resolution? Message-ID: <3C3ADC3B.F75D2669@vigrid.com> References: <20020108155143.W3532-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > On Mon, 7 Jan 2002, Dan Eischen wrote: > > > I'll also enable full save of the FP state in getcontext(). The > > optimized code will be commented out (i386 version): > > > > /* > > * XXX - Do we really need to save floating point registers? > > * > > * This is an explicit call to get the current context, so > > * shouldn't the caller be done with the floating point registers? > > * Contexts formed by involuntary switches, such as signal delivery, > > * should have floating point registers saved by the kernel. > > I think this is viable. It's essentially what the i386 setjmp() does (for > a smaller context). OK, I'll enable the optimization. > > * As of this writing, the kernel doesn't yet save the FPU state > > * on signal delivery, so a setcontext on the interrupted context > > * may yield incorrect results regardless. > > */ > > #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? > This has proved to > be an insignificant problem for setjmp(). Perhaps all of the i386 > optimizations are backwards anyway :-). Memory bandwidth might be the > bottleneck with fast CPUs. We can always run some performance tests to see if there really is any benefit to the optimizations. -- Dan Eischen 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?3C3ADC3B.F75D2669>