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
    On Wed, 9 Feb 2005, Ingo Molnar wrote:

    > > 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.

    Thanks for the tip. I have schedtool installed, and all audio/MIDI IRQ
    threads, jack threads, and jack clients are now run with higher priorities
    than everything else. Before I adjusted priorities, I was getting a bunch
    of these when running latencytest (which have since disappeared):

    rtc: lost some interrupts at 8192Hz.
    bug in rtc_read(): called in state S_IDLE!

    IRQ 8 (RTC) is still giving me some issues, even after adjusting
    priorities:

    `IRQ 8'[232] is being piggy. need_resched=0, cpu=0
    Read missed before next interrupt

    Should the RTC IRQ be given a new priority? If so, should it be lower,
    higher, or equal to the audio/MIDI/jack priorities?

    > 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

    <snip>

    > what is the longest wakeup latency the tracer shows? You can start the
    > measurement anew via:
    >
    > echo 0 > /proc/sys/kernel/preempt_max_latency

    Max latency is in the realm of 13-18 after runs of jack_test4.1.

    > 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.)

    See http://www.sysex.net/testing/ for the all of the test results and
    system info on a 2.6.11-rc3-RT-V0.7.38-06 kernel.

    This is from my most recent run of jack_test4.1 with wmcube and kernel
    compilation running (check /testing/dmesg for more):

    ( sshd-5940 |#0): new 4 s maximum-latency wakeup.
    ( IRQ 16-1803 |#0): new 5 s maximum-latency wakeup.
    ( make-28375|#0): new 6 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 6 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 7 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 8 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 8 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 9 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 10 s maximum-latency wakeup.
    ( ksoftirqd/0-2 |#0): new 10 s maximum-latency wakeup.
    ( jackd-29348|#0): new 12 s maximum-latency wakeup.
    ( jackd-29348|#0): new 14 s maximum-latency wakeup.
    ( jackd-29348|#0): new 15 s maximum-latency wakeup.

    > 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.

    Wmcube displays a 3D spinning cube, which spins faster (actually performs
    larger rotations between updates) when CPU usage goes up. When running
    niced, wmcube uses about 1% to 4% of the CPU, adds about 1000 context
    switches per second, and increases X load by 1% to 3% of the total CPU.

    Now that the priorities are tuned, I get no xruns while running wmcube,
    compiling a kernel, and running latencytest or jack_test4.1.

    > > 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 {

    This patch does fix the MIDI playback BUG I was seeing.


    Best Regards,
    --William Weston <weston at sysex.net>

    -
    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.161 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site