lkml.org 
[lkml]   [1998]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Interesting scheduling times
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:44    [W:3.417 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site