software multitasking or hardware?

[DruG5t0r3]

Which one is the fastest?

[Brendan]

Hi,

Which one is the fastest?

In general software multi-tasking is faster because often you don't need to change the entire CPU state.

If you do need to change the entire CPUs state (i.e. all segment registers, the LDT, the page directory, etc) then it should be fairly similar.

It's possibly worth mentioning that the performance difference is going to depend on how often your OS does a task switch, and that minimizing how often task switches occur is typically far more important.

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.


Cheers,

Brendan

[DruG5t0r3]

Thanks

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.

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.

[Pype.Clicker]

Which one is the fastest?

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 ...

[Therx]

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?

Pete

[Brendan]

Hi,

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?

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.

The exception handler would save the FPU/MMX/SSE state for the previous task and load the new state for the current task before returning from the exception.

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.


Cheers,

Brendan

[Pype.Clicker]

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.

And since you're likely to have the information about whether the next task has FPU context aswell, you can even go for

Code: Select all

if (next->fpu && current->fpu) {
   change_fpu_state(current,next);
} else {
   set_ts_bit();
}