[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0
    Nigel Gamble wrote:
    > Spinlocks should not be held for lots of time. This adversely affects
    > SMP scalability as well as latency. That's why MontaVista's kernel
    > preemption patch uses sleeping mutex locks instead of spinlocks for the
    > long held locks.


    what worries me about this is the Apache-flock-serialisation saga.

    Back in -test8, kumon@fujitsu demonstrated that changing this:


    into this:


    had the effect of *decreasing* Apache's maximum connection rate
    on an 8-way from ~5,000 connections/sec to ~2,000 conn/sec.

    That's downright scary.

    Obviously, <stuff> was very quick, and the CPUs were passing through
    this section at a great rate.

    How can we be sure that converting spinlocks to semaphores
    won't do the same thing? Perhaps for workloads which we
    aren't testing?

    So this needs to be done with caution.

    As davem points out, now we know where the problems are
    occurring, a good next step is to redesign some of those
    parts of the VM and buffercache. I don't think this will
    be too hard, but they have to *want* to change :)

    Some of those algorithms are approximately O(N^2), for huge
    values of N.

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

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