Date: Thu, 10 Jan 2002 14:25:33 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Nate Williams <nate@yogotech.com> Cc: Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, Dan Eischen <eischen@vigrid.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <Pine.SUN.3.91.1020110132409.987A-100000@pcnet1.pcnet.com> In-Reply-To: <15421.49903.523526.956561@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2002, Nate Williams wrote:
> > The context save buffer is 512 bytes long. It isn't
> > all used yet, but will be at some point in the future as long as you use
> > the defined fxsave/fxrstor instructions.
>
> Is the function call the same for the newer processors, such that we can
> just increase the size of the buffer to 512 bytes, and it will work on
> all current CPUs.
I think we're going to need a libc version bump soon :(
> > When a userland application does a getcontext(), the kernel looks at
> > fpcurthread to see if the calling process/thread/whatever has got its
> > context stored in the pcb or in the live registers. There is no need to
> > copy state to the FPU solely in order for the userland to save a copy.
>
> So, if we make getcontext/setcontext a system call, we could do things
> more effeciently. However, part of the reason why it would be nice to
> have get/setcontext as userland calls is that it makes userland thread
> scheduling much more effecient since it doesn't require system calls.
To summarize a few things:
o A trap will occur whenever you access the FPU, but this will
occur only once while the process (or KSE) is executing. Once
a process (KSE?) has the FPU, no other traps will occur until
the process/KSE is swapped out and back in again. So traps
are limited to once per process/KSE resumption. (And I mean
"I don't have the FPU" traps, not other FPU traps.) This
is true of i386, but is it true for other archs, or is the
FPU state always restored for those archs?
o For non-threaded applications, getcontext and setcontext
will always result in a system call (to get/set the signal
mask).
o POSIX/SUSv2 mandate that the context passed out to a signal
handler can be used in a setcontext() call. Other threads
(or contexts) may be run after the signal and before resuming
the context originally passed to the signal handler. This
means that the FPU state must be contained in the context
passed to the signal handler.
o The threads library or other application, may make many
context switches before it is preempted.
We also have sort of agreed that we only care about FPU state
being in ucontext during signal delivery (in the KSE case, it
will probably also need to be there when the thread/KSE is
preempted).
From the threads library point of view, I see it as a win
by having these functions as library routines. That's not
to say that we can't just implement them in the threads
library that way though. But if we're going to implement
them in user space once, why do we need them as syscalls?
--
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?Pine.SUN.3.91.1020110132409.987A-100000>