lkml.org 
[lkml]   [1999]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Common IRQ pitfall results in lockup.
Date
From
Raj, Ashok wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]

> Another one i would recommend if this is making its way to the base
> linux kernel is that we should ask the irq handlers to return some
> value so that the kernel could know who took this interrupt. so if 2
> devices are sharing an interrupt, and if the kernel calls the first
> registered handler, and it knew its device interrupted, then on
> returning from the irq handler if we return 1 to indicate this
> interrupt is consumer, we possibly dont need to send this to all of
> the registered handlers?

That would prevent us calling the second interrupt handler. However,
at that point, the context-switch has already happened, and many
devices (Network cards, serial cards) may "group" interrupts in such a
way that they don't interrupt for EVERY small thing that happens.

So suppose I have two serial devices on one interrupt. If one of them
interrupts, it pays enormously to empty ALL the recieve buffers,
"while we're at it". This is one of the reasons why serial.c doesn't
allocate the request per port that uses that interrupt, but registers
just one interrupt routine that handles all ports that use that
interrupt, and then has a LOOP in the interrupt routine that starts
over flushing buffers once the last port on that interrupt is done, in
the hope of preventing/postponing one interrupt in the future.


Let me try to clarify this with an example. Suppose two serial ports
share IRQ 5 and that not both of these are handled by the standard
serial driver, such that there are two interrupt handlers on the irq
chain.

Suppose both of these end up recieving data at 115k2. If the IRQ
happens after 8 chars that's about 1000 interrupts per second.

Once you have one interrupt from the FIRST on the chain, it will drain
its buffer, and mark "my device caused this". A few hundred
microseconds later the other will interrupt. Thus the steady state is
that you now have 2000 interrupts per second (expensive context
switches...), and are calling 3000 IRQ handlers per second. (1000
times per second only the first is called.)

If you always call all handlers, you will end up calling the second
handler and always have it piggyback on the first handlers interrupt:
Only 1000 interrupts per second, and an average of 2000 interrupt
handlers called per second.

Roger.

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
"I didn't say it was your fault. I said I was going to blame it on you."

-
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.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:3.350 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site