Date: Sat, 12 Jan 2002 12:19:19 -0800 From: Peter Wemm <peter@wemm.org> To: Dan Eischen <eischen@vigrid.com> Cc: Bruce Evans <bde@zeta.org.au>, 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: <20020112201919.B4CBF39EA@overcee.netplex.com.au> In-Reply-To: <3C40451E.5AC30582@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020112201919.B4CBF39EA>