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

Lee Revell
2004-07-29T01:56:29Z

On Wed, 2004-07-28 at 21:08, Lee Revell wrote:
> On Wed, 2004-07-28 at 17:50, Lee Revell wrote:
> > On Wed, 2004-07-28 at 01:05, Ingo Molnar wrote:
> > > * Lee Revell <rlrevell@joe-job.com> 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?
> >
> > With L2, 1:3, max_sectors_kb=256, and the above change, the performance
> > is truly amazing. Over 20 million interrupts, on a 600Mhz machine, the
> > worst latency I was able to trigger was 46 usecs. There does not seem
> > to be any adverse affect on any aspect of the system.
> >
>
> Here are some more results. I am up to 56 million interrupts and I have
> yet to trigger a latency higher than 46 usecs. It looks like this is a
> hard upper limit.

I have also found that if I stress the VM subsystem severely using
sysbench --threads=128 --test=memory, jackd will not start, eventually
its watchdog thread will kill it before it opens the audio ports. It
seems likely that under pressure the mlockall() would never return. I
can add some debugging code to jackd if you need to see which system
call is timing out.

Lee