RTL threads have very simple state (not by coincidence) so this argument, whatever merits it may have for Linux, is not relevant.
On Wed, Nov 28, 2001 at 03:19:19PM -0600, [EMAIL PROTECTED] wrote: > > 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/ -- [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/
