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

[Andrew Morton]

Tim Wright wrote:
> 
> Hmmm...
> if <stuff> is very quick, and is guaranteed not to sleep, then a semaphore
> is the wrong way to protect it. A spinlock is the correct choice. If it's
> always slow, and can sleep, then a semaphore makes more sense, although if
> it's highly contented, you're going to serialize and throughput will die.
> At that point, you need to redesign :-)
> If it's mostly quick but occasionally needs to sleep, I don't know what the
> correct idiom would be in Linux. DYNIX/ptx has the concept of atomically
> releasing a spinlock and going to sleep on a semaphore, and that would be
> the solution there e.g.
> 
> p_lock(lock);
> retry:
> ...
> if (condition where we need to sleep) {
>     p_sema_v_lock(sema, lock);
>     /* we got woken up */
>     p_lock(lock);
>     goto retry;
> }
> ...

That's an interesting concept.  How could this actually be used
to protect a particular resource?  Do all users of that
resource have to claim both the lock and the semaphore before
they may access it?

There are a number of locks (such as pagecache_lock) which in the
great majority of cases are held for a short period, but are 
occasionally held for a long period.  So these locks are not
a performance problem, they are not a scalability problem but
they *are* a worst-case-latency problem.

> 
> I'm stating the obvious here, and re-iterating what you said, and that is that
> we need to carefully pick the correct primitive for the job. Unless there's
> something very unusual in the Linux implementation that I've missed, a
> spinlock is a "cheaper" method of protecting a short critical section, and
> should be chosen.
> 
> I know the BKL is a semantically a little unusual (the automatic release on
> sleep stuff), but even so, isn't
> 
>         lock_kernel()
>         down(sem)
>         <stuff>
>         up(sem)
>         unlock_kernel()
> 
> actually equivalent to
> 
>         lock_kernel()
>         <stuff>
>         unlock_kernel()
> 
> If so, it's no great surprise that performance dropped given that we replaced
> a spinlock (albeit one guarding somewhat more than the critical section) with
> a semaphore.

Yes.

-