On Fri, 22 Jul 2005, Andrew Morton wrote:
>
> Is the benchmark actually doing floating point stuff?
It must be. We still do lazy FP saves.
> We do have the `used_math' optimisation in there which attempts to avoid
> doing the FP save/restore if the app isn't actually using math.
No, it's more than that. There's a per-processor "used_math" flag to
determine if we need to _initialize_ the FPU, but on context switches we
always assume the program we're switching to will _not_ use FP, and we
just set the "fault on FP" flag and do not normally restore FP state.
It seems volanomark will always use FP, if this is the hot path.
We'll only save the FP context if the thread has used the FP in _that_
particular time-slice (TS_USEDFPU).
As to why volanomark also uses FP, I don't know. I wouldn't be surprised
if the benchmark was designed by somebody to not benefit from the x87
state save optimization.
On the other hand, I also wouldn't be surprised if glibc (or similar
system libraries) is over-eagerly using things like SSE instructions for
memcopies etc, not realizing that they can have serious downsides. I don't
see why volanomark would use FP, but hey, it's billed as a java VM and
thread torture test for "chatrooms". Whatever.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
