From owner-freebsd-arch Fri Jan 25 21:44: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A417437B400 for ; Fri, 25 Jan 2002 21:44:05 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA06667; Fri, 25 Jan 2002 22:42:50 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q5gnF47638; Fri, 25 Jan 2002 22:42:49 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15442.16857.446446.208426@caddis.yogotech.com> Date: Fri, 25 Jan 2002 22:42:49 -0700 To: Daniel Eischen Cc: Nate Williams , Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: References: <15441.59822.481182.325298@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > > The kernel knows if the FPU has been used and it also knows > > > > > the format (x87 vs SSE/XMM). As long as the FPU context > > > > > comes from the kernel, then it can also tell us whether > > > > > it is valid and it's format. > > > > > > > > Right, but this has a huge effect on the userlands threads scheduler, > > > > since multiple threads can be active during one time-slice, so the > > > > userland scheduler will have no way of knowing which thread used the > > > > FPU. (At least, not w/out making a system call, defeating most of the > > > > advantages of having userland threads...) > > > > > > I think it only matters when threads are preempted or trap. > > > > With KSE's, won't threads be pre-empted? (I guess they won't unless you > > get an upcall from the kernel, so the flag could get set.) > > I'm not sure, but if you resume a preempted thread without > running any other threads or signal handlers in between, then > you don't have to restore the FPU state anyways. Possibly. > It'll still > be in the pcb and the next trap will load it into the FPU. > Unless the thread is allowed to migrate between KSEs... Eggsactly. :) > > > Can't we treat normal system calls as we would library routines (if > > > you call a function then shouldn't the compiler assume the FPU state > > > could be trashed and be forced to save and restore FPU state that it > > > needs?). > > > > This is much less effecient, since the kernel normally doesn't touch the > > FPU state. (FPU operations in the kernel are illegal currently.) > > A system call looks the same way to an application as any other > library routine doesn't it? Usually, but not always. But, it causes the application to give up it's current scheduling slot, which isn't optimum. > The compiler doesn't know that sigprocmask() is different than > scanf(). Right, but scanf doesn't require saving/restoring the FPU context, while system calls might. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message