OSDev.org

matute81 wrote:But I have an answer, must I do FPU context switch like described in Intel software dev man?

• do the "automatically saving FPU/MMX/SSE state on task switches" thing as described in Intel's manual; which does not work for multi-CPU
• do the "automatically saving FPU/MMX/SSE state on task switches" thing as described in Intel's manual; but use IPIs to force it to work for multi-CPU
• adapt the "automatically saving FPU/MMX/SSE state on task switches" thing described in Intel's manual, so that the state is saved during the task switch if it was used, and the state is loaded during the "device not available" exception if it's needed (not during task switches)
• adapt the "automatically saving FPU/MMX/SSE state on task switches" thing described in Intel's manual, so that the state is always saved during the task switch if it was used, and loaded during the task switch (if the task has used the FPU/MMX/SSE previously)
• just save the FPU/MMX/SSE state during task switches (regardless of whether it's used or not); and forget about the TS flag and "device not available" exception

t's simple. You can clean TS during task switching but it is not effective. You would use FXSAVE/FXRSTOR but only after "clts" instruction. It's seems to me that Intel manual has error in action sequence.

Intel doc wrote:On a task switch, the operating system task switching code must execute the following pseudo-code to set the TS flag according to the current owner of the x87 FPU/MMX/SSE/SSE2/SSE3/SSSE3/SSE4 state. If the new task (task B in this example) is not the current owner of this state, the TS flag is set to 1; otherwise, it is set to 0.

IF Task_Being_Switched_To ≠ x87FPU_MMX_XMM_MXCSR_StateOwner
   THEN
      CR0.TS ← 1;
   ELSE
      CR0.TS ← 0;
FI;

Intel doc wrote: If a new task attempts to access an x87 FPU, MMX, XMM, or MXCSR register while the TS flag is set to 1, a device-not-available exception (#NM) is generated. The device-not-available exception handler executes the following pseudo-code.

FXSAVE “To x87FPU/MMX/XMM/MXCSR State Save Area for Current x87FPU_MMX_XMM_MXCSR_StateOwner”;
FXRSTOR “x87FPU/MMX/XMM/MXCSR State From Current Task’s x87FPU/MMX/XMM/MXCSR State Save Area”;
x87FPU_MMX_XMM_MXCSR_StateOwner ← Current_Task;
CR0.TS ← 0;

Brendan wrote: For all of the choices, performance will vary. For example, for the second choice, if all tasks always use FPU/MMX/SSE then you'd have the overhead of the "device not available" exception and the overhead of the IPI/s for no reason (but if no tasks use FPU/MMX/SSE then you avoid overhead); and for the last choice, if all tasks don't use FPU/MMX/SSE then you'd have the overhead saving the FPU/MMX/SSE state for no reason (but if all tasks always use FPU/MMX/SSE then you avoid overhead).

• Moving average of FPU use by this thread (0 = no FPU use, 1 = FPU used in every timeslice)
• Moving average of thread FPU use on this core in average reporting period (0 = no threads use the FPU, 1 = one thread uses the FPU in reporting period, and so on)
• Realtime nature of thread

• For realtime threads, the FPU state is always always saved immediately; this allows the thread to start executing on whichever node is most promptly available without requiring IPIs to fetch state.
• For threads which have an average FPU usage of 0.5 or greater (or whatever is experimentally determined to be most efficient), FPU state is restored at the start of the time slice
• For threads on cores which have an average FPU usage of 1.5 or greater (or whatever is experimentally determined to be most efficient), FPU state is saved at the end of a time slice

adapt the "automatically saving FPU/MMX/SSE state on task switches" thing described in Intel's manual, so that the state is always saved during the task switch if it was used, and loaded during the task switch (if the task has used the FPU/MMX/SSE previously)

Combuster wrote:Read the previous post: it doesn't. He's apparently using cooperative scheduling.