From owner-freebsd-arch Thu Jan 10 11:26:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0255437B427 for ; Thu, 10 Jan 2002 11:26:40 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0AJPXDH012518; Thu, 10 Jan 2002 14:25:33 -0500 (EST) Date: Thu, 10 Jan 2002 14:25:33 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Peter Wemm , Nate Williams , Dan Eischen , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <15421.49903.523526.956561@caddis.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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