lkml.org 
[lkml]   [2004]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs
    From
    Date
    On Wed, 2004-07-28 at 01:05, Ingo Molnar wrote:
    > if your soundcard doesnt share the irq line with any other 'heavy'
    > interrupt then you can make the irq 'direct' via a simple change to
    > arch/i386/kernel/irq.c, change this line from:
    >
    > #define redirectable_irq(irq) ((irq) != 0)
    >
    > to:
    >
    > #define redirectable_irq(irq) (((irq) != 0) && ((irq) != 10))
    >
    > (if the soundcard is on IRQ 10).
    >
    > does such a change combined with v=3 fix the latencies you are seeing?

    This fixes the PS/2 problem, but running iozone still produces these
    (very small, ~0.1ms) XRUNs:

    ALSA /home/rlrevell/cvs/alsa/alsa-driver/alsa-kernel/core/pcm_lib.c:139: XRUN: pcmC0D2c
    [<c01066a7>] dump_stack+0x17/0x20
    [<de93d54b>] snd_pcm_period_elapsed+0x27b/0x3e0 [snd_pcm]
    [<de979211>] snd_emu10k1_interrupt+0xd1/0x3c0 [snd_emu10k1]
    [<c01078d7>] handle_IRQ_event+0x47/0x90
    [<c0107e93>] do_IRQ+0xe3/0x1b0
    [<c0106268>] common_interrupt+0x18/0x20
    [<c020793c>] ide_dma_intr+0x7c/0xa0
    [<c02014a9>] ide_intr+0xf9/0x1a0
    [<c01078d7>] handle_IRQ_event+0x47/0x90
    [<c0107c3f>] do_hardirq+0xaf/0x180
    [<c011a9bb>] irqd+0x9b/0xc0
    [<c0128514>] kthread+0xa4/0xb0
    [<c0104395>] kernel_thread_helper+0x5/0x10

    This is with the default max_sectors_kb of 1024. If I turn this down
    to 512, I do not get these, but I did get this one, only once:

    ALSA /home/rlrevell/cvs/alsa/alsa-driver/alsa-kernel/core/pcm_lib.c:139: XRUN: pcmC0D2c
    [<c01066a7>] dump_stack+0x17/0x20
    [<de93d54b>] snd_pcm_period_elapsed+0x27b/0x3e0 [snd_pcm]
    [<de979211>] snd_emu10k1_interrupt+0xd1/0x3c0 [snd_emu10k1]
    [<c01078d7>] handle_IRQ_event+0x47/0x90
    [<c0107e93>] do_IRQ+0xe3/0x1b0
    [<c0106268>] common_interrupt+0x18/0x20
    [<c0262957>] schedule+0x2c7/0x580
    [<c02630d7>] schedule_timeout+0x57/0xa0
    [<c015df61>] do_poll+0xa1/0xc0
    [<c015e0b1>] sys_poll+0x131/0x220
    [<c0106047>] syscall_call+0x7/0xb

    If I turn max_sectors_kb down to 256, I do not get any XRUNs at all,
    and the maximum delay reported by running JACK for 5 minutes (several
    million soundcard IRQs) is only 42 usecs! Previously, with 1:2, I could
    only get this down to ~120 usecs, and this required setting max_sectors_kb
    to 32-64. Going any lower than this did not reduce latency any more, it
    seems like some other code path is responsible.

    I am not seeing the latency spikes at ~8 second intervals that Thomas reported.
    Could this be a bug in latencytest?

    Lee



    -
    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:04    [W:6.228 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site