On Fri, Mar 10, 2000 at 02:20:15AM +0100, Ingo Molnar wrote:
>
> On Thu, 9 Mar 2000 yodaiken@fsmlabs.com wrote:
>
> > The result is that we don't need the extra spinlock, but we freeze the
> > IOAPIC until the ack. I don't know whether this freezes all irqs or
> > "only" irqs that are lower hardware priority, but it's a major change
> > in irq semantics and one with interesting performance implications.
>
> it 'freezes' no IRQ at all, the IO-APIC can have any number of outstanding
> IRQs. The IO-APIC will not post any further IRQs of that vector, but that
Ok. That makes things much better. I had understood something different
from you in a previous message.
> is a welcome thing: most IRQ handlers do a loop over some status register,
> so multiple requests can be coalesced. The local-APIC only accepts
> higher-priority interrupts while unacked, but this was an intended change:
So what happens on a uniprocessor when
level triggered arrives
no-ack dispatch of level trigger
higher priority level arrives
dispatch second driver
ack.
Acks are not vector specific, so does the unacked level irq assert again?
BTW: Is it correct to say that
ack after a level causes a operation on both local and io-apic
ack after an edge is purely local.
If so, what happens with
level triggered arrives
no-ack dispatch of level trigger
higher priority EDGE arrives
ack (intended to ack edge)
Does the local apic do acks in stack order?
Is it now an error to do __sti in interrupt mode?
What happens on
level triggered arrives
no-ack dispatch of level trigger
timer irq arives
ack (intended to ack edge)
process switch from timer code.
> IRQ handlers should be atomic and must not rely on other IRQs arriving
> during the handler. (This APIC handling method is btw. similar to what NT
> uses.)
I hope that most drivers comform already, otherwise ....
Consider what might happen on a slow disk drive
disk_irq:
...
note error
reset
wait for a jiffie to see if it's happier
Suppose we have a slow disk drive and a fast network card. On machine
A the drive gets the higher priority hardware vector and things fail.
On system B the drive gets the lower priority vector ...
I really dislike hardware interrupt priorities since they have nothing
to do with the OS' ideas of importance and are complex to work with.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.- 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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:21 EST