[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

Ingo Molnar <mingo(a)elte.hu> wrote: What were those workloads? Certainly 2.6+preempt is not as good as 2.4+LL at this time, but 2.6 isn't too bad either. Even under heavy filesystem load it's hard to exceed a 0.5 millisecond holdoff. There are still a few problem in the ext3 checkpoint buffer handling, but those seem pretty hard to hit. I doubt if the `Jack' testers were running `dbench 1000' during their testing. All of which makes me suspect that the problems which the `Jack' testers saw were not directly related to long periods of non-preemption in-kernel. At least, not in core kernel/fs/mm code. There have been problem in the past in places like i2c drivers, fbdev scrolling, etc. What we need to do is to encourage audio testers to use ALSA drivers, to enable CONFIG_SND_DEBUG in the kernel build and to set /proc/asound/*/*/xrun_debug and to send us the traces which result from underruns. As for the patch, well, sprinkling rescheduling points everywhere is still not the preferred approach. But adding more might_sleep() checks is a sneaky way of making it more attractive ;) Minor point: this: cond_resched(); function_which_might_sleep(); is less efficient than function_which_might_sleep(); cond_resched(); because if function_which_might_sleep() _does_ sleep, need_resched() will likely be false when we hit cond_resched(), thus saving a context switch. Unfortunately, might_sleep() calls tend to go at the entry to functions, whereas cond_resched() calls should be neat the exit point, or inside loop bodies.