Messages in this thread | | | Date | Sat, 13 Jan 2001 00:30:46 +1100 | From | Andrew Morton <> | Subject | Re: [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.
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.
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |