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 [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
