From owner-freebsd-arch Fri Jan 25 15:49:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 8A58537B41D for ; Fri, 25 Jan 2002 15:49:11 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UG5U-0002Dy-00; Fri, 25 Jan 2002 15:48:52 -0800 Message-ID: <3C51EEDF.E1439C5B@mindspring.com> Date: Fri, 25 Jan 2002 15:48:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Paterson Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <200201252303.g0PN36P13616@grendel.twistedbit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Chuck Paterson wrote: > You could allow a user process post and address to the kernel for the > kernel to update when the FPU goes into the used state. Or for that > matter arrange for 1 or more page of kernel space to hold this type > of stuff that an a libray to look at them > > This way you can get at the used bit without the cost of a system > call. Consider the following case, where you are doing this: You are running on two CPUs with a combination of FPU using and non-FPU using threads. An FPU using thread is running on one machine, enters the user space threads scheduler, and there is a time slice based invluntary context switch, leaving that instance of the backing KSE associated with code that is in the user space scheduler. Now some FPU using threads tasks which were running on the suspended-in-the-scheduler CPU complete (e.g. disk or network I/O waits), and are resumed on the second CPU. What happens if there was an FPU exception pending, but not delivered at the time of the involuntary context switch, such that the copy out of the FPU state does not end up where it was expected? Then once again, you are screwed. I don't see a way to get around this, without locking, or an IPI between CPUs running the threads of a single program, to notify one scheduler from the other that the program has started using the FPU. Even doing this would require setting the FPU disable bit, taking the fault, handling by enabling it on a per process basis, and doing an IPI to any other CPU also serving the thread, *before* returning from handling the fault. Any other approach leaves large race windows. I think if you *knew*, up front, that the program was capable of using the FPU, or if you *knew* when it loaded code that would be capable of using it, that you would be covered. The only case this would break down would be code that could generate FPU code and execute it, all by itself (this might be a JIT/JVM issue: Nate should comment ...though I think it unlikely that you would generate FPU instructions without having any yourself). The fix for this would be to have a compiler or linker flag to force the setting of the "FPU=1" flag, even if no FPU instructions are generated by the compiler. In fact, a more elegant way to handle this would be to put a "#pragma flagsection("FPU=1")" into the code where it generates the offending FPU instructions; you could use it for other nifty flags, later, as well. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message