On Tue, 26 Jul 2005, Chuck Ebbert wrote: > > Since fxsave leaves the FPU state intact, there ought to be a better way to > do > this but it gets tricky. Maybe using the TSC to put a timestamp in every > thread > save area?
We used to have totally lazy FP saving, and not toucht he FP state at _all_ in the scheduler except to just set the TS bit. It worked wonderfully well on UP, but getting it working on SMP is a major pain, since the lazy state you want to switch back into might be cached on some other CPU's registers, so we never did it on SMP. Eventually it got too painful to maintain two totally different logical code-paths between UP and SMP, and some bug or other ended up resulting in the current "lazy on a time slice level" thing which works well in SMP too. Also, a lot of the cost is really the save, and before SSE2 the fnsave would clear the FPU state, so you couldn't just do a save and try to elide just the restore in the lazy case. In SSE2 (with fxsave) we _could_ try to do that, but the thing is, I doubt it really helps. First off, 99% of all programs don't hit the nasty case at all, and for something broken like volanomark that _does_ hit it, I bet that there i smore than one thread using the FP, so you can't just cache the FP state in the CPU _anyway_. So we could enhance the current state by having a "nonlazy" mode like in the example patch, except we'd have to make it a dynamic flag. Which could either be done by explicitly marking binaries we want to be non-lazy, or by just dynamically noticing that the rate of FP restores is very high. Does anybody really care about volanomark? Quite frankly, I think you'd see a _lot_ more performance improvement if you could instead teach the Java stuff not to use FP all the time, so it feels a bit like papering over the _real_ bug if we'd try to optimize this abnormal and silly case in the kernel. 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/