Subject: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Andrew Morton (akpm_AT_osdl.org)
Date: Sun Jul 11 2004 - 08:25:10 EEST
Ingo Molnar <mingo_AT_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.
This archive was generated by hypermail 2b28 : Sun Jul 11 2004 - 08:34:00 EEST