Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Feb 2002 22:20:40 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        Peter Wemm <peter@wemm.org>, Dan Eischen <eischen@vigrid.com>, <arch@FreeBSD.ORG>
Subject:   Re: getsetcontext system call 
Message-ID:  <20020212215001.Q3960-100000@gamplex.bde.org>
In-Reply-To: <Pine.GSO.4.10.10202110756480.4-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Feb 2002, Daniel Eischen wrote:

> On Mon, 11 Feb 2002, Bruce Evans wrote:
> > Well, signals handlers should get a clean FPU state, and you don't
> > want spend much time looking at the current state to see if it is
> > clean.  Saving the state into the ucontext and initializing a clean
> > state without looking is probably best.  For i386's without fxsr,
> > saving the state loads a new, clean state into the FPU whether you
> > want it to or not, so it would be best to pass that state to the signal
> > handler and not put it in the pcb, even though signal handlers probably
> > won't use it (saving it to the pcb would usually be a waste of time,
> > since the state will usually be restored from the ucontext and not
> > from the pcb).  For i386's with fxsr, saving the state doesn't change
> > the state in the FPU, so initializing the clean state in the pcb only
> > is probably better (forget the state in the FPU).
>
> But if you already own the FPU, doing anything in the PCB is a
> waste of time.  You're not going to get a trap to reload the
> state from the PCB, and the next FPU context switch will dump the
> current FPU state to the PCB (overwriting the clean state).

You don't really own it, because the signal handler needs a different
context.  That context is probably best provided by putting it in the
PCB, since the signal handler is unlikely to actually use it.  (The
optimal implementation of it is probably to put only a single bit in
the PCB -- a flag that says that the state needs initialization.)

This is all for the fxsr case -- in the !fxsr case, fnsave initializes
the FPU to a clean state (too clean; we would have to add an fldcw to
get the default control word).  Since the signal handler rarely uses
this state, it might be best to use the handling for the fxsr case in
all cases.

> > For i386's with or
> > without fxsr, if the signal handler returns it is difficult to tell
> > if the state being "restored" is already in the FPU, since the signal
> > handler may have modified the ucontext.  Copying the ucontext to the
> > pcb and forgetting the state in the FPU seems best in both cases.
>
> But again, if you know that the thread owns the FPU, saving it to
> the PCB doesn't do anything.  Unless you want to drop FPU ownership
> everytime you deliver a signal as alpha does.

I think I do want that.  It is simplest and close to optimal too.
There is no use keeping it, since we will have to reload it when (if)
the signal handler returns.  In sendsig(), we don't save the state in
the PCB; we just save/copy it in/to the ucontext and copy a clean state
to the PCB (or set a bit that says that the state needs cleaning)

> > get_fpcontext() and set_fpcontext() don't have the right semantics for
> > signal handling.  They try too hard to keep the state in the FPU if it
> > is already there, but in sendsig() you never want it (the old state)
> > there.
>
> OK, so we want a clean FPU state whenever signals get delivered,
> saving the old FPU state in the ucontext.  Do you want to drop
> FPU ownership and initialize the clean state in the PCB?  And
> how do you get a clean state for with and without fxsr?  Does
> fninit do it for both?  If we want to initialize the PCB with a
> clean state, where do we copy it from?

I think fninit does enough (not sure).  We can either copy the clean
state from a prepared clean state, or us fninit or whatever in
npxdna() and put only the needs-cleaning bit in the PCB.  Use a copy,
or fninit + fldcw, or just npxinit() to begin with.  We can optimize
it later.  Hmm, npxinit() is heavyweight.

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?20020212215001.Q3960-100000>