Although I think using hardware for reading the FPU tagword is a good
idea I don't think using FNSTENV on every state save is the right
thing to do.
The common state save need is just to switch tasks. This doesn't require
the state saved in a user friendly format. So the fnstenv is typically
overhead.
The exceptional case and the monitoring case (ptrace) should happen
infrequently (we'll I don't really have any ptrace numbers), and when
they do they can be expected to be non-performance critical. If you
want performance the FP exceptions should all be masked.
Removing FNSTENV alone won't work because, pending exceptions may
linger and not be masked... Some exception ~reset~ is needed.
Therefore FXSAVE followed by FNINIT will handle everything. Using
FNINIT also makes the resulting state exactly as it does when
FNSAVE is used.
When an exceptional or ptrace case does come up the state can
be restored and then saved with FNSAVE directly into user memory.
(I believe Linus suggested saving directly into user mem previously.)
In the exceptional case where the state hasn't changed yet (hasn't
been saved and reinited) then no restore is needed, just the
appropriate saving and reinit.
Finally some memory may be saved in the task struct.
>Caveats: This patch doesn't set the OSXMMEXCEPT bit in cr4 since we don't
>have the new exception handler yet. This needs written. Once this is
>written, the various tests that are current something like
>
>if ( (len > 95) &&
> (boot_cpu_data.x86_capability & X86_FEATURE_XMM) &&
> (boot_cpu_data.cr4_features & X86_CR4_OSFXSR) ) {
>}
>
>can be compressed to test just the len and features for X86_CR4_OSXMMEXCEPT.
Before I was able to dig up an SSE patch I made my own changes to the
2.3.3 kernel to support SSE. I have also added an SSE exception handler,
but I have come across an issue that needs discussion.
The issue is signalling the task of the error. There were a few
possibilties for the signal:
1) Take over a remaining signal - I see one lost and one unsused.
This is probably a bad idea...
or
2) Signal the task with SIGFPE and
a) Set the fpstate pointer of sigcontext to point to the fxsaved
state only when the exception is an SSE exception.
or
b) Change nothing in the sigcontext and create a new syscall for
the user to retrieve the extended info. (Though by Doug Ledford)
and/or
3) The task may inform the kernel is wishes to always have the
sigcontext sent with fxsaved state. This request would be
denied if the processor didn't actually support FXSAVE/FXRSTOR.
This bit check could prevent all FP specific state overhead if my
FNSTENV suggestion is implemented.
You can guess my preference - 2a & eventually 3. And here is why:
If a task creates an SSE exception is must either know about SSE or
be executing what it thought was bad opcodes (do we really care about
their task in that case?) If they know about the opcodes and unmask SSE
exceptions, then they should have read the docs about Linux SSE support
and know that we point fpstate to the fxsaved area. I believe the
current deafult handle is simply to exit and doesn't bother with
fpstate at all => no problem there.
Additionally if my above FNSTENV suggestion is implemented then there
will be no need to perform the FP state 'conversion' even in the absence
of 3.
>So, I welcome any comments. Linus, how do these look to you? Personally, I
>would like to quit maintaining them separately, so if there are issues you
>have with the first patch, let me know and I'll see if I can get it fixed.
>It's currently against 2.2.9 BTW. Has it been tested? I've been running with
>the first patch for over a month now (mostly, I've done code reordering and
>other tweaking in that time, but the base code has been done for a while) and
>the second patch just almost as long.
I'd like to see the development split up too. It would be nice
to keep SSE apart from non-SSE PIII work also.
>
>-------- End Original Message --------
>
>As per my last remark. The patches can be found at
>http://www.redhat.com/~dledford/linux_kernel.html
>
>The first patch I talked about is named PIII.patch and the second one is the
>PIII-raid.patch. Enjoy.
I will try to release a patch with in a week which has the support
for 2a built upon my work with the 2.3.x kernels. I suppose
competing patches suck, but I would guess a merge of the two
may be the right answer.
I heard once that x.even.x kernels were meant for bug fixes and
x.odd.x kernels were meant for experimental work. Is that true?
Jason Hartman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/