[lkml]   [2005]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2.6.13-rc3a] i386: inline restore_fpu

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.054 / U:2.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site