Date: Fri, 25 Jan 2002 15:48:47 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Chuck Paterson <cp@twistedbit.com> Cc: Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, k Macy <kip_macy@yahoo.com>, Peter Wemm <peter@wemm.org>, Julian Elischer <julian@vicor-nb.com>, arch@FreeBSD.ORG Subject: Re: KSE question Message-ID: <3C51EEDF.E1439C5B@mindspring.com> References: <200201252303.g0PN36P13616@grendel.twistedbit.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C51EEDF.E1439C5B>