[lkml]   [2003]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Bug 350] New: i386 context switch very slow compared to 2.4 due to wrmsr (performance)
    In article <>,
    Jamie Lokier <> wrote:
    >Dave Jones wrote:
    >> I feel I'm missing something obvious here, but is this part the
    >> low-hanging fruit that it seems ?
    >You have eliminated one MSR write very cleanly, although there are
    >still a few unnecessary conditionals when compared with grabbing a
    >whole branch of the fruit tree, as it were.
    >That leaves the other MSR write, which is also unnecessary.

    No, the other one _is_ necessary. I did timings, and having it in the
    context switch path made system calls clearly faster on a P4 (as
    compared to my original trampoline approach).

    It may be only two instructions difference ("movl xx,%esp ; jmp common")
    in the system call path, but it was much more than two cycles. I don't
    know why, but I assume the system call causes a total pipeline flush,
    and then the immediate jmp basically means that the P4 has a hard time
    getting the pipe restarted.

    This might be fixable by moving more (all?) of the kernel-side fast
    system call code into the per-cpu trampoline page, so that you wouldn't
    have the immediate jump. Somebody needs to try it and time it, otherwise
    the wrmsr stays in the context switch.

    I want fast system calls. Most people don't see it yet (because you need
    a glibc that takes advantage of it), but those fast system calls are
    more than enough to make up for some scheduling overhead.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:33    [W:0.023 / U:6.428 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site