OSDev.org

Hi guys! I read the following statement:

The x86 architecture includes a specific segment type called the Task State Segment (TSS), to store hardware contexts. Although Linux doesn't use hardware context switches, it is nonetheless forced to set up a TSS for each distinct CPU in the system.

I am wondering:

- Why doesn't Linux use the hardware support for context switch?
- Isn't the hardware approach much faster than the software approach?
- Is there any OS which does take advantage of the hardware context switch? Does windows use it?

At last and as usual, thanks for your patience and reply.

The answer to 2) is, it's not faster on modern architectures. Which pretty much answers 1), too.

see http://forum.osdev.org/viewtopic.php?t=13678

This can now be seen at Stack Overflow: http://stackoverflow.com/questions/2711 ... ia-the-tss

AFAIK, hardware context switching with a TSS is slow mainly because it loads all segment registers, causing a lot of protected mode checks. This is unnecessary overhead in a flat memory model. If you are using a segmented memory model, hardware context switching may be faster (though I've never tested this).

Let us not forget that in long mode, hardware context switching is not even supported at all.

Consider it on par with segment registers: It was a solution for a given problem of its time, has long since been left behind by newer developments, and would have gone the way of the Dodo if it wasn't for x86_64 still being downward compatible to CPU architecture from the seventies and eighties.

multi-segment architecture was aimed at MULTICS environment style. Programming 16-bit code forced you to toy with multiple segments ... you had no choice. It was sort of a nightmare to do, but it was worth it. The UNIX model is simpler, and while it doesn't offer the same level of protection, at least it lets you build things rather than trying work around "artificial" constraints.

IIrc, selective flushing of page tables and fast user-to-system call makes inter-process switches roughly as efficient as your single-address-space-with-multi-segments switches could be. And if that doesn't fullfill your needs for protection, we received Java and other language-oriented protection mechanism to offer the same kind of safeguards as segments where meant to offer.

As for OSes that use it - I don't think any modern ones are (except perhaps for some hobby ones and that's just because their authors don't know it's slower). Linux 0.01 used it; perhaps later versions too, I don't know when they've switched to software-based task switching.

Btw, nice to see you again, Pype.Clicker

Love4Boobies wrote:except perhaps for some hobby ones and that's just because their authors don't know it's slower

I'm using hardware task switching even though I know its slower :p
at the moment I'm not aiming to provide a fast OS but a stable one (or one that works at all) but that may change in the future.. anyway I'll run some tests as soon as the kernel is done. spose it might be interesting to have some actual measurement data

Personally, I think that using software task switching is easier to implement. The TSS is messy and, as everyone else said, reloading segment registers is slow. Plus, if you use software switching, porting to another arch is a breeze (when I moved to x86_64 a week ago, I only needed to alter the IDT handlers and memory management, the process manager code stayed virtually identical)

that's true, but hardware task switching has the advantage that task's dont need to have operating system code in their address space. In a software switched environment you need to have kernel functions such as save and restore (well that's what they're called in Minix) mapped to each task's pagedir.

Hardware task switching also has the advantage that you don't have to take care of the stacks. When an exception causes (for instance) the page fault handler task to be called, the error code is pushed on the stack of the page fault handler. You don't have to execute the page fault handler on behalf of the user task. This is also the reason why double faults can not be handled reliably without hardware task switching.

Anyway, I know that software task switching is a lot more efficient and the advantages of hardware task switching are probably invalid as soon as one has a deep understanding of what is done during a software task switch.
Still, I'll first implement hardware task switching and software task switching afterwards.

Hi,

mkruk wrote:that's true, but hardware task switching has the advantage that task's dont need to have operating system code in their address space. In a software switched environment you need to have kernel functions such as save and restore (well that's what they're called in Minix) mapped to each task's pagedir.

If the OS is lame (e.g. no SMP and no FPU/MMX/SSE support, no keeping track of how much CPU time tasks have used, etc) then it might work, but only if you're willing to accept severe performance problems (due to excessive task switches and excessive TLB misses) for no reason.

mkruk wrote:Hardware task switching also has the advantage that you don't have to take care of the stacks. When an exception causes (for instance) the page fault handler task to be called, the error code is pushed on the stack of the page fault handler. You don't have to execute the page fault handler on behalf of the user task. This is also the reason why double faults can not be handled reliably without hardware task switching.

For the double fault exception handler using hardware task switching (even if/when the OS uses software task switching for everything else) can be a good idea, because the double fault exception handler needs to assume the rest of the kernel has been trashed and typically does a kernel panic and never returns. Of course a double fault only happens if an exception occurs while the CPU is trying to start a different exception handler, so in practice (for a kernel that doesn't have a broken IDT or unreliable kernel stacks) double fault never happens.

For something like the page fault exception handler hardware task switching is a complete nightmare, because hardware task switching isn't reentrant. For example, if you get a page fault while you're trying to handle a previous page fault then the previous page fault handler's stack gets trashed; and this makes it hard to implement support for things like swap, memory mapped files, etc. For example, a page fault occurs, the page fault handler asks the disk driver to load a page of data from disk, the disk driver gets pre-empted by another task (or blocks, waiting for hardware/IRQ), the next task causes a second page fault, and the first page fault handler's stack gets trashed.


Cheers,

Brendan