Also what is drawback of tss based task switching other than it is slower than software task switching? Thanx...hardware task switch
-
Ozguxxx
hardware task switch
Hi, I want to ask something about hardware task switching: Reading older threads about this subject I read that it is necesary to build a new tss descriptor in gdt for each new thread into tss but I dont think this is necessary, I am using only one tss descriptor for all the threads(for now, in kernel mode) do you think that might cause any problems? Please be careful, I have one tss for each thread but only one tss DESCRIPTOR for all threads. Also what is drawback of tss based task switching other than it is slower than software task switching? Thanx...
Also what is drawback of tss based task switching other than it is slower than software task switching? Thanx...
Re:hardware task switch
Hmm... last time I looked, the sentence "tss based task switching is slower than software task switching" evaluated to false unless you added some conditionals...Ozguxxx wrote: Also what is drawback of tss based task switching other than it is slower than software task switching?
Every good solution is obvious once you've found it.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:hardware task switch
TSS-based switch is slower in the case of intra-process thread switch. In this case, a stack switch will keep all page table cache unchanged (thus reducing the need for re-loading the TLBs) while switching to another TSS will flush the TLB.
so far, this is the only inconvenient i've found to hardware task switching.
For Clicker, i opted for an hybrid scheme where each thread can decide whether it is hosted by the process's TSS or owns its TSS. This gives me the wanted protection and control for "system" threads while keeping the ability of creating process that will be heavily multithreaded and execute at top speed because they'll all share the same TSS.
so far, this is the only inconvenient i've found to hardware task switching.
For Clicker, i opted for an hybrid scheme where each thread can decide whether it is hosted by the process's TSS or owns its TSS. This gives me the wanted protection and control for "system" threads while keeping the ability of creating process that will be heavily multithreaded and execute at top speed because they'll all share the same TSS.
-
mystran
Re:hardware task switch
People sometimes argue that software task-switching is more portable, which might be true in some cases, but then again task-switching is hardware specific in any case on lowest level.
My personal reason for implementing software task-switching instead of hardware, is that it makes life somewhat easier in my design, since every userspace thread is backed by a kernel thread anyway.
The main disadvantage would be permissions. At least manipulating io-bitmaps with a software task-switching system means copying data around. At least Linux seems to do this.
Then again, if the rest of the code doesn't depend on the actual method, it's always possible to implement it both ways and benchmark.
My personal reason for implementing software task-switching instead of hardware, is that it makes life somewhat easier in my design, since every userspace thread is backed by a kernel thread anyway.
The main disadvantage would be permissions. At least manipulating io-bitmaps with a software task-switching system means copying data around. At least Linux seems to do this.
Then again, if the rest of the code doesn't depend on the actual method, it's always possible to implement it both ways and benchmark.