Messages in this thread | | | Date | Sat, 10 Jul 2004 22:25:10 -0700 | From | Andrew Morton <> | Subject | Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
Ingo Molnar <mingo@elte.hu> wrote: > > I took a > look at latencies and indeed 2.6.7 is pretty bad - latencies up to 50 > msec (!) can be easily triggered using common workloads, on fast 2GHz+ > x86 system - even when using the fully preemptible kernel!
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |