Thema: IRQs ganz ohne EOI?

[erik.vikinger]

Hallo,


ich bin beim nachdenken über meinen IRQ-Controller auf ein interessantes Problem gestoßen:  benötigt man eigentlich unbedingt einen EOI-Mechanismus?

Beim klassischen PIC (für x86) ist es ja so das wenn der einen Interrupt an eine CPU ausgeliefert hat das er dann erst mal keine weiteren IRQs meldet, auch nicht von anderen Geräten aber gerade letzteres ist ja bei SMP eher doof. Das heißt das mein IRQ-Controller eigentlich nur den gerade ausgelieferten IRQ sperren darf und dieser dann mit seinem individuellen EOI am Ende seines IRQ-Handlers wieder frei gegeben werden müsste. Aber gerade individuelle EOIs kosten wieder zusätzliche Logik im IRQ-Controller und auch ein paar zusätzliche Befehle im Kernel da der ja wissen muss welchen IRQ er da gerade als beendet melden möchte.
Da stellt sich dann aber die Frage:  kommen eigentlich vom selben Gerät weitere IRQs während der IRQ-Handler bereits aktiv ist?
Ganz ausschließen kann man das sicher nicht also muss man das per SW abfangen (wenn man das nicht per HW macht). Da ich die IRQs bei meinem Micro-Kernel-OS eh per asynchronem IPC an die Treiber-Prozesse liefern möchte ist es eigentlich zuverlässig ausgeschlossen das ein und der selbe IRQ-Handler (als PopUp-Thread) mehrfach aufgerufen wird, es wird dann im Kernel gequeued (da eine IRQ-Message ja nur konstant ein paar Bytes benötigt ist das auch kein Speicherproblem). Dafür kann ich mir das EOI-Zeugs komplett sparen und das spart dann bei jedem IRQ etliche Takte ein.

Seht Ihr in meinen Gedanken da irgendwo einen Fehler oder würdet Ihr aus anderen Gründen vom Verzicht auf EOI eher abraten?
Sonstige Anregungen oder Vorschläge dazu?


Grüße
Erik

[Svenska]

Hallo,

was passiert, wenn mehr Interrupts ankommen, als du in einer gegebenen Zeit verarbeiten kannst? Du darfst nur eine begrenzte Anzahl an IRQ-Handle-Popup-Threads queuen, sonst führt ein IRQ-Storm zum Soforttod des Systems.

Wahrscheinlich sinnvoll wären level-triggered Interrupts, die du einfach beim Gerät abnickst. Ist die IRQ-Leitung in der CPU immernoch auf high-Pegel, muss wohl irgendwo ein weiterer Interrupt aktiv sein. Schwierig wird es erst, wenn das Gerät nahezu dauerhaft die IRQ-Leitung aktiv hält, weil die IRQs zu schnell einlaufen.

Ob das viel Logik im Controller ist, kann ich nicht einschätzen. Du wirst aber ohnehin eine Möglichkeit haben, bestimmte Interrupts maskieren zu können und genau diese Funktion kannst du für das EOI-Konzept auch benutzen. Der Controller maskiert den Interrupt einfach, wenn er einläuft. Damit verhinderst du so einen IRQ-Sturm zuverlässig; dieses auto-maskieren kannst du von einem Flag abhängig machen, wenn du feststellst, dass du den Mechanismus wirklich nicht brauchst.

Gruß,
Svenska

[oern]

Hallo,

ich glaube, dass der PIC einen EOI braucht, sonst sendet er den Interrupt gar nicht mehr. Jedenfalls hatte ich den EOI in einem meiner Interrupthandler mal vergessen und habe mich gewundert, warum der IRQ nicht wieder gesendet wird. Oder verstehe ich dich falsch und du entwickelst selber einen PIC?

Gruß,
oern

[erik.vikinger]

Hallo,

Oder verstehe ich dich falsch und du entwickelst selber einen PIC?

Ich entwickle eine komplette Plattform und da ist der IRQ-Controller nur ein kleiner Teil von.

was passiert, wenn mehr Interrupts ankommen, als du in einer gegebenen Zeit verarbeiten kannst? Du darfst nur eine begrenzte Anzahl an IRQ-Handle-Popup-Threads queuen, sonst führt ein IRQ-Storm zum Soforttod des Systems.

Das hängt vor allem von der Priorität der Interrupts ab. Die CPUs nehmen nur Interrupts an deren Priorität höher ist als die Priorität des gerade ausgeführten Codes. Also wenn erst ein IRQ mit niedriger Priorität kommt und dann einer mit einer etwas höheren Priorität dann kann der Erste vom Zweiten unterbrochen werden, falls nicht noch andere CPUs gerade auch Code mit niedriger Priorität ausführen. Wenn alle IRQs die selbe Priorität haben dann werden nur maximal so viele IRQs parallel verarbeitet wie CPUs da sind (da gilt dann wer zuerst kommt ist auch als erstes dran). Ich denke zu einem System-Tod kann es ziemlich sicher nicht kommen.

Wahrscheinlich sinnvoll wären level-triggered Interrupts, die du einfach beim Gerät abnickst. Ist die IRQ-Leitung in der CPU immernoch auf high-Pegel, muss wohl irgendwo ein weiterer Interrupt aktiv sein. Schwierig wird es erst, wenn das Gerät nahezu dauerhaft die IRQ-Leitung aktiv hält, weil die IRQs zu schnell einlaufen.

Eigentlich möchte ich nur MSI einsetzen, das wären dann reine edge-triggered IRQs. In so fern brauch ich eigentlich eh nichts zum maskieren. Wenn eine MSI-Message ankommt wird der zugehörige Zähler inkrementiert und ein Zähler != 0 zeigt an das der IRQ pending ist. Der IRQ-Controller versucht dann den pending IRQ mit der höchsten Priorität an eine CPU zu bringen und das klappt nur wenn es auch eine CPU gibt die gerade Code mit niedrigerer Priorität ausführt als dieser IRQ hat ansonsten muss der IRQ-Controller warten. Die CPU-INT-Leitung wird nur für das ausliefern der IRQs an die CPUs benutzt zeigt aber nur an das der IRQ-Controller überhaupt einen IRQ ausliefern möchte und nicht welcher es ist oder wie viele andere noch warten. Das Ausliefern der IRQs ist ein rein serieller Prozess aber sobald ein IRQ erfolgreich ausgeliefert wurde kann sofort mit dem Ausliefern des nächsten pending IRQ weitergemacht werden.

Ob das viel Logik im Controller ist, kann ich nicht einschätzen. Du wirst aber ohnehin eine Möglichkeit haben, bestimmte Interrupts maskieren zu können und genau diese Funktion kannst du für das EOI-Konzept auch benutzen.

Naja, es gibt pro IRQ ein Enable-Bit aber das ist ein reines RW-Bit in einem Register und wird nicht durch andere Vorgänge beeinflusst, außerdem kann ich dieses eine Bit ja nicht für unterschiedliche Dinge parallel benutzen sonst könnte man ja mit einer EOI-Message einen IRQ enablen obwohl der gar nicht freigegeben wurde und auch nie ausgelöst hat. Was IMHO Logik kosten wird ist das empfangen, dekodieren und verarbeiten der EOI-Messages von den CPUs und genau das möchte ich mir sparen.

Der Controller maskiert den Interrupt einfach, wenn er einläuft. Damit verhinderst du so einen IRQ-Sturm zuverlässig

Jedes mal wenn so eine MSI-Message beim IRQ-Controller ankommt wird nur ein Zähler inkrementiert und wenn das Gerät viele MSI-Messages schickt bis der IRQ endlich an eine CPU ausgeliefert werden kann dann sieht die SW einfach nur einen hohen Zählerwert aber ausgeliefert wird der IRQ nur einmal weil der Zähler beim ausliefern auf 0 gesetzt wird und damit der IRQ nicht mehr pending ist. Damit wäre bei dem Ohne-EOI-Konzept die Sache für den IRQ-Controller auch schon erledigt und sobald eine weitere MSI-Message für diesen IRQ kommt geht der wieder auf pending und wird erneut versucht an eine CPU auszuliefern. Bei der Version mit EOI würde der IRQ-Controller erst dann wieder versuchen den IRQ auszuliefern wenn auch das zugehörige EOI vom letzten Ausliefern gekommen ist. Hier kommt dann eben die Frage wie oft es vorkommt das ein Gerät einen IRQ erneut auslöst während der IRQ-Handler noch läuft. Das würde zwar keinen weiteren IRQ-Handler-Aufruf im Treiber bedeuten (das verhindert mein IPC-System eh schon zuverlässig) aber es kostet natürlich trotzdem einige CPU-Takte den IRQ in SW zu queuen. Hier könnte man dann ja im Kernel einen Sicherheitsmechanismus einbauen so das wenn ein IRQ zu oft kommt während der zugehörige IRQ-Handler noch läuft das dann der IRQ komplett disabled wird (wimre gibt es im Linux-Kernel auch so einen Sicherheits-Mechanismus). Bei ordentlicher HW, die nicht mit IRQs wild um sich schmeißt, kann die Version ohne EOI aber einiges an CPU-Arbeit sparen (und auch etwas Logik) und genau das ist mein Ziel.


Grüße
Erik

[Svenska]

Hallo,

an die Hardware würde ich keine Ansprüche stellen, denn diese liegt außerhalb deines Systems (es sei denn, du möchtest jegliche Peripherie auch noch entwickeln ).

Hardware, die IRQ-Stürme verursacht, tut dies nicht immer. Meine 3Com 3c589 liefert zwar zuverlässig die volle Datenrate, verursacht dabei aber Unmengen an IRQs. Irgendwann fängt der Treiber an, die Karte nur noch zu pollen und deaktiviert Interrupts. Das scheint mir aber keine Kernelfunktion, sondern eine Funktion des Treibers zu sein. Das tritt aber nur auf, wenn ich minutenlang(!) Videos streame.

Das eigentliche EOI ist das Zurücksetzen des Zählers in deinem Fall. Wenn du Interrupts in Software priorisieren können möchtest, musst du dem Controller irgendwie mitteilen, welchen Interrupt du nun gerade verarbeitest und das ist dein EOI. Willst du kein EOI, dann muss der Interrupt Controller wissen, welcher (von den potentiell mehreren aktiven) Interrupts gerade verarbeitet wird. Du darfst dann aber unter keinen Umständen einen Interrupt in der CPU verlieren, sonst kommt die Synchronisation aus dem Konzept.

Du müsstest dem Interrupt Controller trotzdem mitteilen, dass du einen Interrupt jetzt fertig verarbeitet hast. Da sollte aber - bei gegebener Priorisierung - ein unkonditionelles ACK im Handler ausreichen. Dann müsstest du aber garantieren, dass du die ACKs auch in der Reihenfolge schickst, wie die Interrupts ankamen...

</glaskugelgucken>

Svenska

[erik.vikinger]

Hallo,

an die Hardware würde ich keine Ansprüche stellen

Naja, ein paar Basis-Komponenten werde ich wohl schon selber entwickeln bzw. hab ich schon fertigen VHDL-Code. Aber Recht hast Du schon das Hardware nicht grundsätzlich als gutartig und vertrauenswürdig eingestuft werden kann. Um dem Problem häufiger IRQs Herr zu werden könnte man im IRQ-Controller die Maximal-Frequenz mit der ein bestimmter IRQ ausgeliefert wird begrenzen, das würde zwar auch Logik kosten aber wenigstens keine CPU-Takte. Also um die Systemsicherheit und Zuverlässigkeit zu erhöhen bin ich grundsätzlich schon bereit Logikressourcen zu investieren aber das EOI würde mir eben keine zusätzlichen Features bringen und immer (auch bei gutem Wetter) zusätzliche CPU-Takte kosten.

Meine 3Com 3c589 liefert zwar zuverlässig die volle Datenrate, verursacht dabei aber Unmengen an IRQs. Irgendwann fängt der Treiber an, die Karte nur noch zu pollen und deaktiviert Interrupts.

Hm, ob eine 3Com 3c589 da ein gutes Beispiel ist? Die ist doch seit mindestens 15 Jahren veraltet. Was ist den bei einer 10MBit-Karte die maximale Frequenz an Interrupts? Ich komme auf etwa 16kHz pro Richtung für 64Byte-Frames ohne Lücken und da das so gar nicht geht vermute ich mal es sind eher so maximal 10kHz und in der realen Praxis wo die Ethernet-Frames eher 1500 Bytes haben kommt deutlich unter 1 kHz bei raus. Klar der IRQ-Handler für die 3c589 ist sehr CPU-intensiv weil er die Daten händisch per PIO aus der Karte rausholen muss aber grundsätzlich empfinde ich persönlich 1 oder 2 kHz Interruptfrequenz noch nicht als so kritisch. In meinem Konzept soll eine Ethernet-Karte 3 unabhängige IRQs haben: einmal fürs Empfangen, einmal fürs Senden und einmal fürs Management (Kabel dran/ab u.ä.). Auf diese Art können Empfangen und Senden komplett unabhängig von einander auf unterschiedlichen CPUs laufen.

Das scheint mir aber keine Kernelfunktion, sondern eine Funktion des Treibers zu sein.

Das mit dem Sicherheitsmechanismus im Linux-Kernel hat mir ein Kumpel erzählt der recht fit ist in Sachen Linux-Kernel, aber ich frage ihn da noch mal etwas genauer.

Das tritt aber nur auf, wenn ich minutenlang(!) Videos streame.

Du streamst Video über 10 MBit? Respekt! So viel Leidensbereitschaft hätte ich Dir gar nicht zugetraut.

Das eigentliche EOI ist das Zurücksetzen des Zählers in deinem Fall.

Genau. Ein IRQ hat nur 2 Zustände im IRQ-Controller: inaktiv (Zähler == 0) und pending (Zähler != 0). Den dritten Zustand "wird gerade von der SW bearbeitet" möchte ich mir gerne sparen weil da das Weiterschalten immer von der SW händisch gemacht werden muss.

Wenn du Interrupts in Software priorisieren können möchtest, musst du dem Controller irgendwie mitteilen, welchen Interrupt du nun gerade verarbeitest und das ist dein EOI.

Ähh, da verstehe ich jetzt nicht was Du meinst. Dem IRQ-Controller ist es egal was gerade auf den CPUs läuft, er versucht einfach immer den pending IRQ mit der höchsten Priorität auszuliefern (falls überhaupt irgendein IRQ auf pending ist) und ob das überhaupt von einer CPU angenommen wird entscheiden die CPUs anhand der Priorität des IRQ und der gerade ausgeführten SW (die sehen also ständig die Priorität dieses pending IRQ und können daher selber entscheiden und die CPUs sehen auch die niedrigste SW-Priorität die gerade von irgendeiner CPU ausgeführt wird so das möglichst nur diese CPU sich den IRQ holt).

Willst du kein EOI, dann muss der Interrupt Controller wissen, welcher (von den potentiell mehreren aktiven) Interrupts gerade verarbeitet wird.

Wozu muss der IRQ-Controller das wissen? Er weiß ja noch nicht einmal wie viele CPUs überhaupt vorhanden sind.

Du darfst dann aber unter keinen Umständen einen Interrupt in der CPU verlieren, sonst kommt die Synchronisation aus dem Konzept.

Ja, verlieren darf ich absolut keinen IRQ. Da sehe ich aber auch keine Gefahr. Ich denke nicht das es einen Unterschied macht ob die nächsten IRQs in HW gequeued werden (weil das EOI noch nicht gekommen ist) oder ob die in SW gequeued werden (weil der aktuelle IPC-Vorgang noch läuft). Ich denke bei guter Hardware dürfte grundsätzlich nur sehr wenig gequeued werden weil die ja nicht für ein und die selbe Sache immer wieder MSI-Messages los schickt.

Du müsstest dem Interrupt Controller trotzdem mitteilen, dass du einen Interrupt jetzt fertig verarbeitet hast. Da sollte aber - bei gegebener Priorisierung - ein unkonditionelles ACK im Handler ausreichen. Dann müsstest du aber garantieren, dass du die ACKs auch in der Reihenfolge schickst, wie die Interrupts ankamen...

Hm, auch hier verstehe ich nicht was Du mir damit sagen willst. Wenn verschiedene IRQs auf unterschiedlichen CPUs bearbeitet werden dann spielt es doch keine Rolle ob die in der selben Reihenfolge fertig werden wie sie ausgeliefert wurden. Stell Dir mal vor was passieren würde wenn der schnelle IRQ-Handler auf den langsamen warten müsste, ne das will ich nicht.


Grüße
Erik

[Svenska]

Hallo,

In meinem Konzept soll eine Ethernet-Karte 3 unabhängige IRQs haben: einmal fürs Empfangen, einmal fürs Senden und einmal fürs Management (Kabel dran/ab u.ä.). Auf diese Art können Empfangen und Senden komplett unabhängig von einander auf unterschiedlichen CPUs laufen.

Solange sich die Hardware nicht dran hält, nutzt dir das wenig.

Das tritt aber nur auf, wenn ich minutenlang(!) Videos streame.

Du streamst Video über 10 MBit? Respekt! So viel Leidensbereitschaft hätte ich Dir gar nicht zugetraut.

Ich habe eine D-Box2, allerdings keinen Fernseher. Also werden die Daten da rausgestreamt, stramm mit maximal 10 MBit - mehr kann die Box nicht.

Wie gesagt, nach ein paar Minuten wird der Interrupt abgeschaltet.

Das eigentliche EOI ist das Zurücksetzen des Zählers in deinem Fall.

Genau. Ein IRQ hat nur 2 Zustände im IRQ-Controller: inaktiv (Zähler == 0) und pending (Zähler != 0). Den dritten Zustand "wird gerade von der SW bearbeitet" möchte ich mir gerne sparen weil da das Weiterschalten immer von der SW händisch gemacht werden muss.

Also doch ein EOI. Der Zustand "wird gerade von der Software verarbeitet" existiert bei pegelgesteuerten Interrupts (PIC -> CPU, nicht Hardware -> PIC) nicht, da der Interrupt solange aktiv ist, wie der Zähler >0 ist; und zurücksetzen musst du ihn eh. Das heißt, jeder Interrupthandler muss zwei ACKs rausschicken, einmal an die Hardware und einmal an den PIC.

Um das zu vermeiden, muss die Hardware direkt mit pegelgesteuerten Interrupts arbeiten, aber das hast du ja schon ausgeschlossen.

Dem IRQ-Controller ist es egal was gerade auf den CPUs läuft, er versucht einfach immer den pending IRQ mit der höchsten Priorität auszuliefern (falls überhaupt irgendein IRQ auf pending ist) und ob das überhaupt von einer CPU angenommen wird entscheiden die CPUs anhand der Priorität des IRQ und der gerade ausgeführten SW (die sehen also ständig die Priorität dieses pending IRQ und können daher selber entscheiden und die CPUs sehen auch die niedrigste SW-Priorität die gerade von irgendeiner CPU ausgeführt wird so das möglichst nur diese CPU sich den IRQ holt).

Das heißt, dass Interrupts bei dir prinzipiell niedriger priorisiert sind (sein können) als die aktuell laufende Software? Soweit ich das jetzt verstanden habe, möchtest du prinzipiell mehrere IRQ-Handler für verschiedene Hardware parallel ablaufen lassen können, je CPU ein Handler. Das heißt, es gibt nicht nur einen pending IRQ, sondern prinzipiell mehrere; deren Handler können unterschiedlich schnell werden und das erzwingt direkt einen EOI-Mechanismus für "ich bin fertig".

Ich denke bei guter Hardware dürfte grundsätzlich nur sehr wenig gequeued werden weil die ja nicht für ein und die selbe Sache immer wieder MSI-Messages los schickt.

Falsche Grundvoraussetzung: "gute Hardware".

Grundsätzlich muss ich an dieser Stelle das Thema eher abschließen.

Error: Not enough Ahnung.

[erik.vikinger]

Hallo,

In meinem Konzept soll eine Ethernet-Karte 3 unabhängige IRQs haben: einmal fürs Empfangen, einmal fürs Senden und einmal fürs Management (Kabel dran/ab u.ä.). Auf diese Art können Empfangen und Senden komplett unabhängig von einander auf unterschiedlichen CPUs laufen.

Solange sich die Hardware nicht dran hält, nutzt dir das wenig.

Also moderne Ethernet-Karten können das, vielleicht ließt Du Dir doch mal das e1000-Driver-Developer-Manual durch. Ganz im Ernst, aktuelle Hardware ist durchaus dafür ausgelegt ihre IRQ-Last auf mehrere IRQs und damit potentiell auf mehrere CPUs zu verteilen.

.....
Wie gesagt, nach ein paar Minuten wird der Interrupt abgeschaltet.

Naja, als so toll empfinde ich diese Idee trotzdem nicht. Wenn die IRQs zum Problem werden dann werden sie einfach abgeschalten, klingt für mich eher nach ner Verzweiflungstat als nach nem klugen Konzept.

Das eigentliche EOI ist das Zurücksetzen des Zählers in deinem Fall.

Genau. Ein IRQ hat nur 2 Zustände im IRQ-Controller: inaktiv (Zähler == 0) und pending (Zähler != 0). Den dritten Zustand "wird gerade von der SW bearbeitet" möchte ich mir gerne sparen weil da das Weiterschalten immer von der SW händisch gemacht werden muss.

Also doch ein EOI.

Das Ausliefern eines IRQ an eine CPU quittiert ihn auch gleich automatisch in meinem Ohne-EOI-Konzept. Auf das Ausliefern kann man nicht verzichten, irgendwie muss die CPU ja schließlich die IRQ-Nummer erfahren, aber diesen Vorgang möchte ich komplett in Hardware realisieren (so wie es bei x86 u.v.a.m. auch ist).

Der Zustand "wird gerade von der Software verarbeitet" existiert bei pegelgesteuerten Interrupts (PIC -> CPU, nicht Hardware -> PIC) nicht

Ist für PIC -> x86 und meine Plattform (und wohl die meisten anderen auch) zutreffend.

da der Interrupt solange aktiv ist, wie der Zähler >0 ist

Oder die pegelbasierte IRQ-Leitung von der Hardware zum PIC noch aktiv ist.

und zurücksetzen musst du ihn eh.

Klar. Die hier gestellte Frage ist: "Wann?". Also mit welchen Vorgang wird der IRQ im IRQ-Controller quittiert?
Um die CPU von doppelter Kommunikation mit dem IRQ-Controller zu entlasten möchte ich das Quittieren gleich mit ins Ausliefern (also das Abholen durch die CPU) mit einbauen.
Das der IRQ auch bei der Hardware quittiert werden muss ist klar und absolut unumgänglich (und HW-spezifisch).

Das heißt, jeder Interrupthandler muss zwei ACKs rausschicken, einmal an die Hardware und einmal an den PIC.

Und gerade den zweiten ACK möchte ich mir sparen, um genau diesen Punkt dreht sich diese Diskussion.

Um das zu vermeiden, muss die Hardware direkt mit pegelgesteuerten Interrupts arbeiten, aber das hast du ja schon ausgeschlossen.

Gerade weil man bei pegel-triggered Interrupts auch zwingend diesen dritten Zustand benötigt (weil ja die HW die IRQ-Leitung nicht sofort mit dem Ausliefern des IRQs an eine CPU deaktiviert, das bekommt die ja auch gar nicht mit) möchte ich MSI einsetzen.

Das heißt, dass Interrupts bei dir prinzipiell niedriger priorisiert sind (sein können) als die aktuell laufende Software?

Grundsätzlich ja. Schließlich könnten ja bestimmte Aufgaben wichtiger sein als einzelne Hardware-Komponenten. Außerdem ist bei einem Micro-Kernel ja auch ein IRQ-Handler nur ganz normale User-Mode-Software (das heißt damit ein IRQ-Handler von einem wichtigen HW-Gerät nicht vom IRQ eines weniger wichtigen HW-Gerätes unterbrochen wird muss der erste IRQ-Handler eine höhere Priorität haben). Grundsätzlich soll bei mir der IRQ und sein zugehöriger SW-IRQ-Handler die selbe Priorität haben (anders wäre ja auch Quatsch).

Soweit ich das jetzt verstanden habe, möchtest du prinzipiell mehrere IRQ-Handler für verschiedene Hardware parallel ablaufen lassen können, je CPU ein Handler.

Exakt, es spricht doch auch nichts dagegen das möglichst alle IRQs möglichst schnell verarbeitet werden (gemäß ihrer Prioritäten natürlich).

Das heißt, es gibt nicht nur einen pending IRQ, sondern prinzipiell mehrere

Ein IRQ der noch auf pending ist wird noch nicht verarbeitet, der wartet also noch darauf das sich eine CPU seiner annimmt und den zugehörigen IRQ-Handler ausführt. Es kann in meinem System also mehrere (viele) pending IRQs gleichzeitig geben (z.B. wenn mehrere IRQs (fast) zeitgleich kommen bevor auch nur einer davon an eine CPU ausgeliefert werden kann) und auch mehrere unterschiedliche IRQs können von den CPUs verarbeitet werden (theoretisch sogar mehr als CPUs vorhanden sind da ein IRQ-Handler ja auch mal sleep(x) benutzen kann und damit eine CPU für begrenzte Zeit frei gibt).

das erzwingt direkt einen EOI-Mechanismus für "ich bin fertig".

Warum? Wenn ein IRQ für den  IRQ-Controller mit der Auslieferung an eine CPU als Erledigt anzusehen ist dann besteht keine Notwendigkeit für einen EOI zum IRQ-Controller.

Falsche Grundvoraussetzung: "gute Hardware".

Da hast Du mich wohl missverstanden, "gute Hardware" ist keine Grundvorausetzung! Aber sie sollte mit möglichst wenig CPU-Einsatz unterstützt werden, solange "schlechte Hardware" nicht das System behindert oder gar gefährdet und da sehe ich momentan keine Gefahr. Siehst Du denn eine Gefahr für das System?

Grundsätzlich muss ich an dieser Stelle das Thema eher abschließen.
Error: Not enough Ahnung.

Das ist extrem doof! Wer sonst hat denn hier noch Ahnung (und Lust mit mir zu Diskutieren)?


Grüße
Erik