From owner-freebsd-arch Sat Jan 12 12:19:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0ADC537B402 for ; Sat, 12 Jan 2002 12:19:21 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020112201920.ILUW10951.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Sat, 12 Jan 2002 20:19:20 +0000 Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0CKJJs73657 for ; Sat, 12 Jan 2002 12:19:19 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B4CBF39EA; Sat, 12 Jan 2002 12:19:19 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dan Eischen Cc: Bruce Evans , Alfred Perlstein , Kelly Yancey , Nate Williams , Terry Lambert , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C40451E.5AC30582@vigrid.com> Date: Sat, 12 Jan 2002 12:19:19 -0800 From: Peter Wemm Message-Id: <20020112201919.B4CBF39EA@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Eischen wrote: > Bruce Evans wrote: > > > > On Fri, 11 Jan 2002, Dan Eischen wrote: > > > > > Peter Wemm wrote: > > > > switching out to another process, then we've wasted a kernel trap, a tw o > > > > 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. > > Hmm. That sucks. But they are no different than setjmp/longjmp, and noone > is complaining about them ;-) > > > > > 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 > > Just the control word right now. Which is enough. Your existing get/setcontext are causing a kernel trap. get/set/make/swapcontext() are useful outside of libc_r. Optimization that is good for libc_r may not be good for everthing else. What I would like is that we have the infrastructure to do it in both roles well. libc_r can provide its own implementation (ie: your current one) which is tuned to the needs of libc_r. For the general purpose one it can call getsetcontext(2) to do the meat of the load/save. Remember, outside of libc_r libc_r's implementation does *two* kernel traps, one for the sigprocmask syscall and one for triggering the FPU state load. Outside libc_r we may as well do it in one single trap for a syscall. We cannot avoid the the trap in that case because we have to take the syscall trap for the signal mask. We have plenty of precedents for this already. eg: select() is different in libc_r vs libc and so on. As are the sigXXX() family. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message