Messages in this thread | | | Date | Sat, 13 Jan 2001 12:01:04 +1100 | From | Andrew Morton <> | Subject | Re: [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.
Yes.
- - 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/
| |