[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-audio-dev] low-latency scheduling patch for 2.4.0
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.023 / U:108.416 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site