software multitasking or hardware?
Posted: Wed Apr 13, 2005 8:18 am
Which one is the fastest?
The Place to Start for Operating System Developers
http://f.osdev.org/
In general software multi-tasking is faster because often you don't need to change the entire CPU state.DruG5t0r3 wrote: Which one is the fastest?
I'm aware of those, whats neat about i386s is that you can actually save/store those states only when they are required by a certain task. which leads to less task switching overhead.There are a pile of other issues involved (like FPU/MMX/SSE state switching, IO port protection, etc). For more information, see http://www.osdev.org/osfaq2/index.php/C ... 0Switching.
That mainly depends on how frequently you do inter-process switch against intra-process switch (e.g. switching thread, but remaining in the same process). When inter-process switches are involved, i'd say the "switching overhead" is rather neglectible compared to the cost of reloading the TLBs with the pages of the new address space ...DruG5t0r3 wrote: Which one is the fastest?
Niether - you don't test if a thread has used the FPU/MMX/SSE. Instead you set the TS flag in CR0 during the task switch so that as soon as the task tries to use an FPU/MMX/SSE instruction it causes an exception.Pete wrote: Kindof on the same topic (something i keep forgetting to ask) - How can you tell if a thread has used FPU/MMX/SSE ? do you have to scan the code for opcodes? or do you just test whether and fpu stuff has changed?
And since you're likely to have the information about whether the next task has FPU context aswell, you can even go forBrendan wrote: Of course you can save the FPU/MMX/SSE state during the task switch if you like. It's easier but isn't as good for performance if some tasks don't use the FPU/MMX/SSE. On the other hand, if all tasks do use the FPU/MMX/SSE then you can prevent the overhead of the extra exception.
Code: Select all
if (next->fpu && current->fpu) {
change_fpu_state(current,next);
} else {
set_ts_bit();
}