[lkml]   [2004]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [announce] [patch] Voluntary Kernel Preemption Patch
    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:
    > (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
    > More majordomo info at
    > Please read the FAQ at

    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.377 / U:0.012 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site