lkml.org 
[lkml]   [2005]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

    * William Weston <weston@sysex.net> wrote:

    > Jackd (-R -P64 -dalsa -dhw:0 -r44100 -p64 -n3 -i2 -o2) w/ one
    > soft-synth client (using 15% to 30% of the CPU) will run for over 12
    > hours without any xruns, even during kernel compiles and nightly
    > updatedb runs.
    >
    > Running wmcube (an impractical, greedy, little CPU meter), even when
    > niced, causes lots of xruns. It may be good for worst-case-scenario
    > desktop load testing.

    this phenomenon is very weird.

    Firstly, make sure that all relevant threads (including the soundcard
    IRQ thread, jackd threads, jack client thread, etc.) have higher RT
    priority than any other, latency-irrelevant threads in the system.

    If everything looks OK on the priority-administration side, could you
    enable wakeup-latency tracing via:

    CONFIG_WAKEUP_TIMING=y
    CONFIG_PREEMPT_TRACE=y
    # CONFIG_CRITICAL_PREEMPT_TIMING is not set
    # CONFIG_CRITICAL_IRQSOFF_TIMING is not set
    CONFIG_LATENCY_TIMING=y
    CONFIG_LATENCY_TRACE=y

    It should look like this in the Kernel Hacking menu of menuconfig:

    [*] Wakeup latency timing
    [ ] Non-preemptible critical section latency timing
    [ ] Interrupts-off critical section latency timing
    [*] Latency tracing

    what is the longest wakeup latency the tracer shows? You can start the
    measurement anew via:

    echo 0 > /proc/sys/kernel/preempt_max_latency

    every new maximum-latency event will be logged by the kernel, and the
    trace of the latest worst-case latency path can be found under
    /proc/latency_trace.

    (If the trace is very long then most of the time it's OK to just send
    the first 25 and last 10 lines. Putting the trace up to a website is a
    good solution too.)

    it should not matter how 'greedy' wmcube is. Does it do alot of graphics
    activity (perhaps 3D too?) - that could in theory cause hardware
    latencies - the latency traces will tell.

    > MIDI playback through any MPU-401 interface triggers the following
    > BUG, reported once for each outgoing MIDI event (non MPU-401 hw
    > interfaces and sw interfaces not affected):

    the patch below should fix this. (also included in -38-06 and later
    kernels.)

    Ingo

    --- linux/sound/drivers/mpu401/mpu401_uart.c.orig
    +++ linux/sound/drivers/mpu401/mpu401_uart.c
    @@ -316,12 +316,12 @@ static void snd_mpu401_uart_input_trigge
    /* read data in advance */
    /* prevent double enter via rawmidi->event callback */
    if (atomic_dec_and_test(&mpu->rx_loop)) {
    - local_irq_save(flags);
    + local_irq_save_nort(flags);
    if (spin_trylock(&mpu->input_lock)) {
    snd_mpu401_uart_input_read(mpu);
    spin_unlock(&mpu->input_lock);
    }
    - local_irq_restore(flags);
    + local_irq_restore_nort(flags);
    }
    atomic_inc(&mpu->rx_loop);
    } else {
    @@ -407,12 +407,12 @@ static void snd_mpu401_uart_output_trigg
    /* output pending data */
    /* prevent double enter via rawmidi->event callback */
    if (atomic_dec_and_test(&mpu->tx_loop)) {
    - local_irq_save(flags);
    + local_irq_save_nort(flags);
    if (spin_trylock(&mpu->output_lock)) {
    snd_mpu401_uart_output_write(mpu);
    spin_unlock(&mpu->output_lock);
    }
    - local_irq_restore(flags);
    + local_irq_restore_nort(flags);
    }
    atomic_inc(&mpu->tx_loop);
    } else {
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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