On Fri, 2004-08-27 at 13:23, Mike Mestnik wrote: > I guess I don't understand, the article said the sound(OSS) took the BKL? > It didn't say that ALSA's OSS is effected, I'm assuming that it is not. > In any case ALSA still uses ioctls. So no mater what sound takes the BKL > and disables preemption? > > I don't think that preemption could work at all, unless when the BKL is > [1]droped you preemptate. I think you have something wrong, as DRI dose > these things alot so it might not block preemption. > > 1. msleep, usercpy, ect. >
The article actually didn't say much about why the BKL affects audio performance. Sound (meaning ALSA) does not take the BKL. When another process takes the BKL, however, preemption is disabled until that process either drops the BKL or goes to sleep. So to minimize audio latency (which is just the amount of time between when a SCHED_FIFO process is made runnable and when it gets the processor), other parts of the kernel need to minimize the amount of time they spend non-preemptible (holding the BKL or a spinlock, or having explicityly disabled preemption). Therefore ioctl is bad and should be avoided wherever possible. It's not a big deal for ALSA, because the ioctls complete very quickly, and they only happen when starting or stopping the audio device anyway. But if we are recording audio and the DRI comes along and spends more than a few hundred usecs in an ioctl(), we are screwed. Like Ingo said, the real fix is to replace the DRM's use of the BKL with fine grained locking. Also please don't top post! Lee ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
