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