[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFP: kernel-patch-voluntary-preempt -- lower kernel latency by voluntary preemption



On Thu, 19 Aug 2004, Robert Jordens wrote:
> Package: wnpp
> Severity: wishlist
>
> Hi debian-multimedia!
>
> Who is interested in packaging this? I can't do it because I only have
> my powerpc to test on which voluntary-preempt is not yet available for.
> I know Guenter already did realtime-lsm (hint..). Someone from Agnula?

Hmm, I probably won't find the time to package this. A kernel patch is
quite different from a kernel module package.
I agree, that it would be nice to have it though, especially if we could
lobby it into the standard Debian kernel (not that I know what it would
take to do that).

Guenter


>
> Thanks.
>
>         Robert.
>
>
>   Package name    : kernel-patch-voluntary-preempt
>   Version         : 2.6.8.1-P4
>   Upstream Author : Ingo Molnar <mingo@elte.hu>
>   URL             : http://people.redhat.com/mingo/voluntary-preempt/
>   License         : GPL
>   Description     : lower kernel latency by voluntary preemption
>
>  From <http://people.redhat.com/mingo/voluntary-preempt/>:
>
>     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/
>
>       (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 and drop the conditional stuff/ifdefs 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
>
> -- System Information:
> Debian Release: 3.1
>   APT prefers testing
>   APT policy: (990, 'testing'), (300, 'unstable')
> Architecture: powerpc (ppc)
> Kernel: Linux 2.6.8-rj1
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
>
> --
> WYSIWYG:
> 	What You See Is What You Get.
>



Reply to: