Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Redeeman]

this all seems pretty cool...
do you think you could make a patch against mm for this? it would be
greatly apreciated

On Fri, 2004-07-09 at 20:26 +0200, Ingo Molnar wrote:
> as most of you are probably aware of it, there have been complaints on
> lkml that the 2.6 kernel is not suitable for serious audio work due to
> high scheduling latencies (e.g. the Jackit people complained). 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!
> 
> to solve this problem, Arjan van de Ven and I went over various kernel
> functions to determine their preemptability and we re-created from
> scratch a patch that is equivalent in performance to the 2.4 lowlatency
> patches but is different in design, impact and approach:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.7-bk20-H2
> 
>   (Note to kernel patch reviewers: the split voluntary_resched type of
>   APIs, the feature #ifdefs and runtime flags are temporary and were
>   only introduced to enable a easy benchmarking/comparisons. I'll split
>   this up into small pieces once there's testing feedback and actual
>   audio users had their say!)
> 
> unlike the lowlatency patches, this patch doesn't add a lot of new
> scheduling points to the source code, it rather reuses a rich but
> currently inactive set of scheduling points that already exist in the
> 2.6 tree: the might_sleep() debugging checks. Any code point that does
> might_sleep() is in fact ready to sleep at that point. So the patch
> activates these debugging checks to be scheduling points. This reduces
> complexity and impact quite significantly.
> 
> but even using these (over one hundred) might_sleep() points there were
> still a number of latency sources in the kernel - we identified and
> fixed them by hand, either via additional might_sleep() checks, or via
> explicit rescheduling points. Sometimes lock-break was necessary as
> well.
> 
> as a practical goal, this patch aims to fix all latency sources that
> generate higher than ~1 msec latencies. We'd love to learn about
> workloads that still cause audio skipping even with this patch applied,
> but i've been unable to generate any load that creates higher than 1msec
> latencies. (not counting driver initialization routines.)
> 
> this patch is also more configurable than the 2.4 lowlatency patches
> were: there's a .config option to enable voluntary preemption, and there
> are runtime /proc/sys knobs and boot-time flags to turn voluntary
> preemption (CONFIG_VOLUNTARY_PREEMPT) and kernel preemption
> (CONFIG_PREEMPT) on/off:
> 
>         # turn on/off voluntary preemption (if CONFIG_VOLUNTARY_PREEMPT)
> 	echo 1 > /proc/sys/kernel/voluntary_preemption
> 	echo 0 > /proc/sys/kernel/voluntary_preemption
> 
>         # turn on/off the preemptible kernel feature (if CONFIG_PREEMPT)
> 	/proc/sys/kernel/kernel_preemption
> 	/proc/sys/kernel/kernel_preemption
> 
> the 'voluntary-preemption=0/1' and 'kernel-preemption=0/1' boot options
> can be used to control these flags at boot-time.
> 
> all 4 combinations make sense if both CONFIG_PREEMPT and
> CONFIG_VOLUNTARY_PREEMPT are enabled - great for performance/latency
> testing and comparisons.
> 
> The stock 2.6 kernel is equivalent to:
> 
>    voluntary_preemption:0 kernel_preemption:0
> 
> the 2.6 kernel with voluntary kernel preemption is equivalent to:
> 
>    voluntary_preemption:1 kernel_preemption:0
> 
> the 2.6 kernel with preemptible kernel enabled is:
> 
>    voluntary_preemption:0 kernel_preemption:1
> 
> and the preemptible kernel enhanced with additional lock-breaks is 
> enabled via:
> 
>    voluntary_preemption:1 kernel_preemption:1
> 
> it is safe to change these flags anytime.
> 
> The patch is against 2.6.7-bk20, and it also includes fixes for kernel
> bugs that were uncovered while developing this patch. While it works for
> me, be careful when using this patch!
> 
> Testreports, comments, suggestions are more than welcome,
> 
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/