Messages in this thread | | | Date | Sun, 12 Mar 2000 09:53:29 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Sun, 12 Mar 2000 yodaiken@fsmlabs.com wrote: > > 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?
Acks _are_ vector specific. It's just that you don't need to specify the vector, because the local APIC knows which one it must be (very simple: it must always be the highest-priority in-service irq).
> 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)
The nesting is always ok, because the local APIC knows which interrupts are in service, and thus also knows which one is "active" (the highest priority in-service one).
I personally think it's a stupid design (it would be so easy for software to just explicitly say _which_ IRQ to ACK, and I don't see the point of not requireing that and make it explicit), but it's straightforward.
> Is it now an error to do __sti in interrupt mode?
No, why would it be?
Doing an __sti in interrupts will let higher-priority interrupts in. As it always has.
I think it's probably stupid most of the time, and shows that something is wrong (an interrupt should not take long enough for it to matter that we do an __sti), but sometimes that kind of stupidity is a result of horrible hardware latencies (eg the time it takes to read a sector from the IDE disk using programmed IO).
> 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.
That would be a horrible bug, and would ALWAYS have been a horrible bug.
Quite regardless of how you do interrupts: it doesn't matter where youput the ACK's, you always need to make sure that irq masking etc is correct, and you must NOT allow a context switch while an interrupt handler is still running.
The kernel _only_ does a process switch on return to user level. That very much includes the case above; the timer interrupt obviously is not returnign to user level.
You're making these problems up.
> I really dislike hardware interrupt priorities since they have nothing > to do with the OS' ideas of importance and are complex to work with.
I agree. I think interrupt controllers should be simple masks, nothing more, nothing less.
However, I'm not designing the hardware.
Linus
- 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/
| |