Re: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

Thomas Charbonnel
2004-07-28T11:45:53Z

> * Lee Revell <rlrevell@joe-job.com> wrote:
>
> > > i've done a softirq lock-break in the atkbd and ps2mouse drivers - this
> > > should fix the big latencies triggered by NumLock/CapsLock, reported by
> > > Lee Revell.
> >
> > L2 does not fix this problem. Previously, toggling CapsLock would
> > trigger a single large XRUN. Now it seems to actually prevent the
> > soundcard interrupt handler from executing in time, as well as
> > triggering smaller XRUNs. This is with preempt=1,
> > voluntary-preempt=3.
>
> yeah, this is because right now irqd lacks any configurability: it is
> executing all hardirqs (and all softirqs) in one context without any
> particular prioritization.
>
> 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?
>
> Ingo

Testing with -L2 and the redirectable_irq change, the xruns triggered by
the keyboard on 8.079 secs boundaries are still here (but the CAPS_LOCK
one is gone since the the redirectable change). I ran some latency tests
with vp:3 kp:0, progressively rising the rtc freqency (2048, 4096), and
I realized that those latency spikes every 8.079 seconds are here even
if I don't touch the keyboard. Here's the typical showtrace output for
those spikes :

T=1.14231 diff=0.978288
rtc_interrupt (+bd)
handle_IRQ_event (+50)
do_hardirq (+bc)
irqd (+ac)
kthread (+aa)
irqd (+0)
kthread (+0)
kernel_thread_helper (+5)

The pattern is very similar to the previous one I reported on those
regular xruns :

XRUN: pcmC2D0c
[<c0105f6e>] dump_stack+0x1e/0x30
[<c03673b1>] snd_pcm_period_elapsed+0x2e1/0x420
[<c039d3d4>] snd_hdsp_interrupt+0x174/0x180
[<c01073bb>] handle_IRQ_event+0x3b/0x70
[<c0107746>] do_IRQ+0x96/0x150
[<c0105b14>] common_interrupt+0x18/0x20
[<c0107746>] do_IRQ+0x96/0x150
[<c0105b14>] common_interrupt+0x18/0x20
[<c01030f4>] cpu_idle+0x34/0x40
[<c054880d>] start_kernel+0x16d/0x190
[<c010019f>] 0xc010019f

The other source of xrun was seen during the disk write tests, once the
memory runs out (spikes up to 14 ms, but more generally 6 ms)

Thomas