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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Fri Jan 12 2001 - 15:30:46 EET


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_AT_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.

-


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jan 12 2001 - 16:06:25 EET