Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[Andrew Morton <andrewm@uow.edu.au>]

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/