lkml.org 
[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0
    Andrew Morton wrote:
    >
    > 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.
    >
    > Nigel,
    >
    > what worries me about this is the Apache-flock-serialisation saga.
    >
    > Back in -test8, kumon@fujitsu demonstrated that changing this:
    >
    > lock_kernel()
    > down(sem)
    > <stuff>
    > up(sem)
    > unlock_kernel()
    >
    > into this:
    >
    > down(sem)
    > <stuff>
    > up(sem)
    >
    > 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.

    If <stuff> was that fast, maybe the down/up should have been a spinlock
    too. But what if it is changed to:

    BKL_enter_mutx()
    down(sem)
    <stuff>
    up(sem)
    BKL_exit_mutex()
    >
    > How can we be sure that converting spinlocks to semaphores
    > won't do the same thing? Perhaps for workloads which we
    > aren't testing?

    The key is to keep the fast stuff on the spinlock and the slow stuff on
    the mutex. Otherwise you WILL eat up the cpu with the overhead.
    >
    > 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 :)

    They will *want* to change if they pop up due to other work :)
    >
    > 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 majordomo@vger.kernel.org
    > Please read the FAQ at http://www.tux.org/lkml/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

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