[lkml]   [2004]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[announce] [patch] Voluntary Kernel Preemption Patch

    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:

    (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

    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)

    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,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:2.197 / U:1.524 seconds]
    ©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site