To:	linux-kernel@vger.rutgers.edu
From:	torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Interesting scheduling times
Date:	17 Sep 1998 17:02:59 GMT

In article <199809170431.OAA20382@vindaloo.atnf.CSIRO.AU>,
Richard Gooch  <rgooch@atnf.csiro.au> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/