Date: Thu, 10 Jan 2002 13:40:12 -0700 From: Nate Williams <nate@yogotech.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: Nate Williams <nate@yogotech.com>, Peter Wemm <peter@wemm.org>, 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: <15421.64556.613206.825107@caddis.yogotech.com> In-Reply-To: <Pine.SUN.3.91.1020110132409.987A-100000@pcnet1.pcnet.com> References: <15421.49903.523526.956561@caddis.yogotech.com> <Pine.SUN.3.91.1020110132409.987A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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 Whenever you *acess* the FPU a trap occurs? I didn't realize this. > , 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. Unless you get an exception (div by zero, etc..), correct? > So traps > are limited to once per process/KSE resumption. (And I mean > "I don't have the FPU" traps, not other FPU traps.) Never mind. > This > is true of i386, but is it true for other archs, or is the > FPU state always restored for those archs? I'll let someone more clued than me respond. > o For non-threaded applications, getcontext and setcontext > will always result in a system call (to get/set the signal > mask). Ok, but we're now assuming that all threading models using libc_r. There may be another threading implementation besides the one in libc_r, so will it have the same functionality as the one in libc_r? (I guess we could always copy the code from there...) > 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. The entire FPU state? > o The threads library or other application, may make many > context switches before it is preempted. What do you mean by context switch in this case? My assumption up to this point is that context switch is a thread of execution changing it's context (be it either kernel threads of userland threads). Using that definition, I'm assuming you mean pre-empted by the kernel doing a process-switch (vs. a context switch) because the userland process has used up it's timeslice. > 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). I haven't agreed. Bruce has stated this, but based on everything else I've read (and the lack of details) we still need to save the entire FPU state when signals are not used. (See the thread.yield() case). > >From the threads library point of view, I see it as a win > by having these functions as library routines. I agree as well. > 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? Good question. Peter brought up some reasons, but I'm not sure they apply to all architectures. Nate 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?15421.64556.613206.825107>