Date: Sat, 12 Jan 2002 17:00:21 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dan Eischen <eischen@vigrid.com> Cc: Peter Wemm <peter@wemm.org>, Alfred Perlstein <bright@mu.org>, Kelly Yancey <kbyanc@posi.net>, Nate Williams <nate@yogotech.com>, Terry Lambert <tlambert2@mindspring.com>, Archie Cobbs <archie@dellroad.org>, <arch@FreeBSD.ORG> Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020112162603.X4598-100000@gamplex.bde.org> In-Reply-To: <3C3F9A46.BBA1A1D5@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Jan 2002, Dan Eischen wrote: > Peter Wemm wrote: > > switching out to another process, then we've wasted a kernel trap, a two > > fpu state loads and two fpu state saves. > > You're assuming that getcontext() gets and saves the current FPU > state. So far we are assuming that it doesn't have to, and swapcontext > wouldn't have to either. swapcontext() would only have to load the > FPU state if the context were gotten by being passed to a signal > handler. [ And I want to fix the kernel so that it places the FPU > state in the sigcontext/ucontext passed to the signal handler. ] The current getcontext/setcontext touch the FPU state even when they don't preserve it (using fnstcw/fninit+fldcw, like setjmp/longjmp), so they cause the same inefficiencies. > > Specifically: > > 0: cpu_switch() to new process. fpu state not loaded (lazy) > > [no fpu activity at all, so the fpu state is still sitting in the pcb] > > 1: user does swapcontext() > > [process does a sigprocmask(2) syscall when being used outside of libc_r] > > 2: userland swapcontext blindly attempts to save fpu state > > Not true. True enough :-). It (the i386 version) blindly attemps to save either the whole FPU state or just the control word. If this causes a trap to load the state from the pcb, then efficiency gained from not saving the whole state is almost irrelevant, since the trap overhead takes longer than fnsave. > If getcontext (and therefore swapcontext) had to save the FPU state, then > I would agree that a syscall would be better, at least in the case of a > non-threaded application. And the first time I implemented get,set,swap > context was with syscalls, so it's not like I'm that biased towards doing > it in userspace :-) I just want fast context switches for the threads > library, and so far I don't see the real need for syscalls anyways. For really fast context switches, I think we need to avoid both FPU switching and ucontext_t-based interfaces. ucontext_t has mounds of stuff in it that is only relevant for switching in signals handlers. Even the limited part of it that is switched by getcontext/setcontext is larger than the part switched by sigsetjmp/siglongjmp (much larger in cycles if switching of the signal mask is not needed, since there is no way to avoid switching it). 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?20020112162603.X4598-100000>