Norm Dresner wrote: > > It's my understanding that the Linux kernel performs FPU-save/restore > for every "task" that it dispatches because it doesn't want to bother > trying to figure out if it needs the FPU or not.
It always saves but restores just if the newly scheduled task attempts to use it. It knows the new tasks wants the FPU through trap 7. See Intel manuals. a shorter explanation "hardware FPU support" at http://www.aero.polimi.it/projects/rtai/, and the i387 stuff in Linux. > Therefore, for > normal processes the FPU contents are always specific to the task that > "owns" the CPU and normal Linux "strongly discourages" kernel > processes from using the FPU by: > 1) providing no FPU services for save/restore > 2) providing (almost) no no-preemption guarantee so it's not even > safe for a (normal) kernel module to try to implement it itself > (unless, I guess, it's an ISR in a single CPU system which always > operates with interrupts disabled). A hold story. Silly assumption for recent CPUs, fully violated in 2.4.xx, as shown by the Stanford code checker. On Athlons I think the kernel is using the FPU even more badly (not so sure). Standard FPU save/restore is in the range of 200 clock cycles, since every kid is now playing with 1G Celeron/Duron are you willing to mess things up just to save .2 us while any interrupt can cause much more latency? I think that even on any 486 still sold there is no use in avoiding the FPU in the kernel. Paolo. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
