Doesnt help. I have potentially infinite interrupt recursion on this driver,
when it goes really wild it will blow 16K of stack. It isnt a fix. We have
to find out how interrupts are getting recursively reentered like that
and stop it
> > 4. We've lost the fast irq stuff. Thats unbelievably bad and may be part
> > of #1.
>
> Unfortunately it would be _big_ task to edit all existing interrupt handlers
> to include a return value (like originally planned). This would be very error
> prone too. Maybe reintroducing the SA_INTERRUPT flag for fast interrupts
> is the best solution for 2.1
I've measured a few things. With the current code you can forget running
a 28.8 modem on a 486 class machine with standard uarts under 2.1, you can
forget running 64K sync cards, you can forget running 9600 baud unbuffered
sync amateur radio and every one of those interrupts is slowing the machine
down far more than before.
Terminal server with 16550A uarts - works in 2.0, forget 2.1
So we _do_ have cases it matters a lot that we have a fast IRQ handling
scheme - even if we can't pull it for SMP machines. Interrupt latency is
becoming the networking bottleneck too, and I suspect some of the small block
fs performance problem.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html