Messages in this thread | | | Date | Fri, 12 Jan 2001 15:08:00 -0800 | From | george anzinger <> | Subject | Re: [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/
| |