Messages in this thread | | | Subject | Re: [PATCH 0/4] Really lazy fpu | From | Valdis.Kletnieks@vt ... | Date | Sun, 13 Jun 2010 16:45:22 -0400 |
| |
On Sun, 13 Jun 2010 18:03:43 +0300, Avi Kivity said: > Currently fpu management is only lazy in one direction. When we switch into > a task, we may avoid loading the fpu state in the hope that the task will > never use it. If we guess right we save an fpu load/save cycle; if not, > a Device not Available exception will remind us to load the fpu. > > However, in the other direction, fpu management is eager. When we switch out > of an fpu-using task, we always save its fpu state.
Does anybody have numbers on how many clocks it takes a modern CPU design to do a FPU state save or restore? I know it must have been painful in the days before cache memory, having to make added trips out to RAM for 128-bit registers. But what's the impact today? (Yes, I see there's the potential for a painful IPI call - anything else?)
Do we have any numbers on how many saves/restores this will save us when running the hypothetical "standard Gnome desktop" environment? How common is the "we went all the way around to the original single FPU-using task" case? [unhandled content-type:application/pgp-signature] | |