<snip>
>> >> 3. "Hardware context switching provided by x86 is not used." This sentence >> is from page 14 on http://www.rtlinux.org/documents/RTLinux.ppt. Is there >> any reason for this? >No comments on this one. Maybe a better person will reply to this others. <snip> To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Linus Torvalds) Subject: Re: Interesting scheduling times Date: 17 Sep 1998 17:02:59 GMT In article <[EMAIL PROTECTED]>, Richard Gooch <[EMAIL PROTECTED]> wrote: > >More importantly, I'm surprised by the slowdown from 2.1.104 to >2.1.122-pre2. What happened is that the very latest 2.1.x kernels are using a software context switch, rather than just a jump through a task-gate and using the hardware context switch code. Intel documents hardware context switching as slow, and various people have at times complained to be about using it. They can now see _why_ I used it. The reason I had to make the context switch be done in software rather than hardware was that I couldn't fix an oops any other way. What happens is that in order to streamline various other parts, I really cannot guarantee that all user-level segment registers are always up-to-date - when processes like Wine and DOSEMU change the LDT, the process context may no longer be valid in another thread, and with the hardware context switching I could force an oops in the context switch that I had no way to recover from. In contrast, with the slightly slower software context switch I can recover gracefully from bad segments. Oh, well. 2.0.x had this same problem too, but it's harder to trigger because threads don't share the LDT in 2.0.x. In addition, in 2.0.x the context switch isn't protected by a spinlock, so the oops was less damaging: in 2.1.x the oops would result in a completely dead system due to the scheduler spinlock being held stale. The new software context switch routine might be slightly optimizable, so we may be able to make it faster, but on the whole it's always easier to make buggy code faster than correct code. And while I am a performance freak, fixing bugs takes precedence.. Oh, another change is that in the later kernels the scheduler also correctly does the "tq_scheduler" bottom half processing, which earlier 2.1.x kernels didn't do because I couldn't handle the kernel lock correctly. That may or may not make a difference. Linus -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
