-
TECHNISCHES GEBIET
-
Diese Anmeldung betrifft die Kommunikation in einem prozessorbasierten System .
-
HINTERGRUND
-
1 ist ein vereinfachtes Blockschaltbild eines Multiprozessorsystems 500 gemäß einigen Ausführungsformen. Das Multiprozessorsystem 500 weist N zentrale Verarbeitungseinheiten (central processing units - CPUs) 150A, 150B, ..., 150 N (kollektiv „CPUs 150“) auf, die mi N - 1 spezialisierten Bussen gekoppelt sind, welche als Quick-Path-Interconnect (QPI)-Busse 160A, 160B, ..., 160N-1 (kollektiv „QPI-Busse 160“) bekannt sind. Die QPI-Busse 160, die spezifisch für die CPUs ausgelegt sind, beschleunigen die Kommunikation zwischen den CPUs 150. Die CPUs können ferner mit einem oder mehreren (nicht gezeigten) flüchtigen Speichern gekoppelt sein.
-
Ferner weist das Multiprozessorsystem 500 bis zu N Peripherie-Controller-Hubs (PCHs) 180A, ..., 180N (kollektiv „PCHs 180“) auf, die über N spezialisierte Busse, welche als Direkt-Medien-Schnittstellen (direct media interface - DMI)-Busse 170A, 170B, ... 170N bekannt sind, mit den CPUs 150 gekoppelt sind. Die PCHs 180 bilden Schnittstellen zwischen den CPUs 150 und einer oder mehreren Peripherievorrichtungen des Multiprozessorsystems 500. Die PCHs 180 können ferner eine Anzeige, Eingangs-/Ausgangs (input/output - I/O)-Steuerung, eine Echtzeituhr und weitere Funktionen aufweisen und können mit einer integrierten Anzeige sowie anderen Peripherievorrichtungen, wie z. B. einer Tastatur, einer Maus, einer nichtflüchtigen Speichervorrichtung und so weiter, verbunden sein.
-
Für eine Kommunikation zwischen Endpunkten innerhalb des Prozessors eines Multiprozessorsystems 500 oder eines einzelprozessorbasierten Systems wird ein Nachrichtenkanal verwendet. Der Nachrichtenkanal ist das Übertragungsmedium für diese Kommunikationen und kann als eine Art von „Tunnel“ oder „Unterführung“ zwischen Endpunkten innerhalb des Prozessors angesehen werden. Es kann viele Nachrichtenkanal-Endpunkte geben, und eine Nachricht kann von jedem Endpunkt zu jedem anderen Endpunkt gesendet werden, wobei die Endpunkte Funktions-Entitäten innerhalb des Prozessors sind. Ein portabler Maschinen-Code oder pcode wird für eine Kommunikation zwischen den Entitäten verwendet, und der pcode weist seinen eigenen Endpunkt zum Senden von Nachrichten zu anderen Endpunkten auf. (Kein Endpunkt sendet eine autonome Nachricht zu dem pcode, da die einzige Nachricht, die von dem pcode-Endpunkt empfangen wird, eine Antwort auf eine Nachricht ist, die der pcode erzeugt hat.) Energieverwaltungsanforderungs (power management request - PMReq)-Nachrichten gehen unter Verwendung des QPI-Busses, der dem Nachrichtenkanal im Wesentlichen gleich ist mit der Ausnahme, dass der QPI-Bus ein(e) externe(r) Bus/Schnittstelle ist, anderen Entitäten zu. Der Nachrichtenkanal ist im Gegensatz dazu ausschließlich innerhalb des Prozessors angeordnet.
-
Bei CPU-basierten Systemen, wie z. B einem Einzelprozessorsystem oder dem Multiprozessorsystem 500 von 1, wird ein Nachrichtenkanal von vielen ungleichartigen pcode-Flows und -Funktionen verwendet. Diese Funktionen können verwendet werden, um Uncore-Steuerregister zu lesen und zu schreiben, PMReqs auszugeben und Nachrichten zu anderen Plattform-Entitäten (z. B. anderen CPUs 150, PCHs 180) zu senden. Der pcode verwendet den Nachrichtenkanal ziemlich häufig, von Hunderten von Malen pro Millisekunde bis Tausenden von Malen pro Millisekunde.
-
Einige neuere Multiprozessorsysteme sind so ausgelegt, dass der Nachrichtenkanal zu verschiedenen Zeiten blockiert sein kann, wie z. B. während eines Frequenzübergangs. Bei früheren Multiprozessorsystemen ist dieses Problem nicht aufgetreten, da ihre Nachrichtenkanal-Schnittstellen immer voll funktionsfähig waren. Somit konnte der pcode bei früheren Projekten den Nachrichtenkanal durch Senden der Transaktion auf den Nachrichtenkanal und Warten in einer engen Schleife auf die Beendigung der Transaktion auf eine „blockierende“ Weise verwenden.
-
Bei neueren Multiprozessorsystemen wird die Anwendung von „blockierenden“ Transaktionen auf dem Nachrichtenkanal als inakzeptabel angesehen, da durch die blockierende Transaktion der pcode für mehrere zehn Mikrosekunden potenziell gesperrt sein kann. Die blockierenden Transaktionen führen somit zu einer größeren Latenz bei anderen (nicht nachrichtenkanalbezogenen) Funktionen und beeinträchtigen die Leistung der CPU. Des Weiteren besteht das Risiko eines Stillstands, da der Nachrichtenkanal durch eine Funktion blockiert ist, die auf irgendetwas wartet, das über eine Seitenband-Schnittstelle von dem pcode kommt, der pcode jedoch blockiert ist, da er auf die Beendigung einer Nachrichtenkanal-Transaktion wartet.
-
Des Weiteren machen PMReq-Nachrichten eine Entscheidung bezüglich der Verwendung eines einzelnen Puffers in einer PMReq-Maschine (PMReq engine - PME) erforderlich. PMReq-Nachrichten laufen über den Nachrichtenkanal zu der PME und dann über den QPI-Bus 160 zu einer weiteren CPU 150 (oder über den DMI-Bus 170 zu dem PCH 180). Als Teil der PMReq-Protokoll-Korrektheit wartet die PME auf eine Beendigung (completion - CMP) aus der anderen CPU/PCH und hält den PMReq-Puffer gesperrt, bis die Beendigung tatsächlich empfangen worden ist. In diesem Fall ist, falls eine blockierende Nachrichtenkanal-Transaktion angewendet wird, der pcode während der Dauer des gesamten Rundlaufs des PMReq/CMP-Austauschs gesperrt. Es kann Verzögerungen auf der anderen CPU geben (aufgrund einer Frequenzänderung etc.), wodurch die Dauer der Sperrung weiter verlängert wird.
-
Somit besteht weiterhin Bedarf an einer Lösung, mit der die Nachteile beim Stand der Technik eliminiert werden.
-
US 2011/0085509 A1 offenbart eine Mobilkommunikationstechnologie und insbesondere ein Verfahren zum effizienten Übertragen von Daten, die in einem Puffer für Nachrichten 3 (Msg3) gespeichert sind. Das Verfahren zum Übertragen von Daten durch ein Benutzergerät im Uplink umfasst das Empfangen eines Uplink-(UP)-Grant-Signals von einer Basisstation bei einer bestimmten Nachricht, das Bestimmen, ob Daten in einem Nachrichten-3-(Msg3)-Puffer gespeichert sind, wenn das UL-Grant-Signal an empfangen wird die spezifische Nachricht, Bestimmen, ob die spezifische Nachricht eine Antwortnachricht mit wahlfreiem Zugriff ist, und Übertragen der im Msg3-Puffer gespeicherten Daten an die Basisstation unter Verwendung des UL-Grant-Signals, das auf der spezifischen Nachricht empfangen wurde, wenn im Msg3-Puffer Daten gespeichert sind Empfangen des UL-Grant-Signals auf der spezifischen Nachricht, und die spezifische Nachricht ist die Direktzugriffs-Antwortnachricht.
-
ABRISS DER ERFINDUNG
-
Der Gegenstand der Erfindung wird durch die unabhängigen Patentansprüche definiert. Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Patentansprüche.
-
Figurenliste
-
Die vorstehend genannten Aspekte und viele der damit in Zusammenhang stehenden Vorteile dieser Patentschrift werden offensichtlich, wenn diese unter Bezugnahme auf die folgende detaillierte Beschreibung in Zusammenhang mit den beiliegenden Zeichnungen besser verständlich werden, wobei sich durchgehend in den verschiedenen Ansichten gleiche Bezugszeichen auf gleiche Teile beziehen, sofern nichts anderes angegeben ist.
- 1 ist ein vereinfachtes Blockschaltbild eines Multiprozessorsystems gemäß einigen Ausführungsformen;
- 2 ist ein vereinfachtes Blockschaltbild des Nachrichtenkanal-Optimierungsverfahrens und -systems gemäß einiger Ausführungsformen;
- 3 ist ein Ablaufdiagramm mit Darstellung eines Task-Flows für zwei Tasks gemäß einigen Ausführungsformen;
- 4 ist ein Ablaufdiagramm mit Darstellung eines Task-Flows für dieselben zwei Tasks wie in 3, wobei dieses Mal das Verfahren und System von 2 angewendet werden, gemäß einigen Ausführungsformen;
- 5 ist ein Ablaufdiagramm im Anschluss an eine Nachrichtenkanal-Sendeoperation, die mittels des Nachrichtenkanal-Optimierungsverfahrens und -systems von 2 verarbeitet wird, gemäß einigen Ausführungsformen; und
- 6 ist ein Ablaufdiagramm im Anschluss an eine Nachrichtenkanal-Leseoperation, die mittels des Nachrichtenkanal-Optimierungsverfahrens und -systems von 2 verarbeitet wird, gemäß einigen Ausführungsformen.
-
DETAILLIERTE BESCHREIBUNG
-
Anhand der hier beschriebenen Ausführungsformen werden ein virtueller Nachrichtenkanal und Treiber zum Ermöglichen eines Multiflow-Zugriffs auf die Nachrichtenkanal-Infrastruktur innerhalb einer CPU eines prozessorbasierten Systems offengelegt. Jedem pcode-Flow, bei dem ein Nachrichtenkanal verwendet wird, ist ein Virtuell-Kanal-Identifizierer zugewiesen. Bei jedem Ablauf mit einem Virtuell-Kanal-Identifizierer kann eine Rückrufadresse registriert werden und kann eine Nachrichtenkanal-Transaktion zur Verarbeitung vorlegt werden. Die Transaktion wird entweder unverzüglich oder zu einem künftigen Zeitpunkt von einem Nachrichtenkanal-Treiber verarbeitet.
-
In der folgenden detaillierten Beschreibung wird auf die beiliegenden Zeichnungen Bezug genommen, die zu Veranschaulichungszwecken spezifische Ausführungsformen zeigen, bei denen der hier beschriebene Gegenstand in die Praxis umgesetzt werden kann. Es versteht sich jedoch, dass andere Ausführungsformen für Durchschnittsfachleute auf dem Sachgebiet beim Lesen dieser Offenbarung offensichtlich werden. Die folgende detaillierte Beschreibung darf daher nicht in einem einschränkenden Sinn ausgelegt werden, da der Schutzumfang des Gegenstands von den Patentansprüchen definiert wird.
-
2 ist ein vereinfachtes Blockschaltbild eines Nachrichtenkanal-Optimierungsverfahrens 100 oder Optimierungsverfahrens 100 gemäß einigen Ausführungsformen. Bei dem Optimierungsverfahren 100 werden virtualisierte Kommunikationsbuchsen zum Ermöglichen eines Multiflow-Zugriffs auf die Nachrichtenkanal-Infrastruktur eines prozessorbasierten Systems verwendet. Bei dem Optimierungsverfahren 100 wird ein Nachrichtenkanal-Treiber 50 verwendet, der eine Schnittstelle zwischen den virtuellen Kanälen 70A, 70B, .., 70K (kollektiv „virtuelle Kanäle 70“) und einem physikalischen Nachrichtenkanal 20, der für eine Kommunikation zwischen Endpunkten innerhalb eines Prozessors des prozessorbasierten Systems verwendet wird, bildet.
-
Bei einigen Ausführungsformen werden mit dem Optimierungsverfahren 100 die in dem Abschnitt Hintergrund beschriebenen Probleme bei Systemen, wie z. B. dem Multiprozessorsystem 500 von 1, durch Verwenden der virtuellen Nachrichtenkanäle 70 anstelle der blockierenden Verwendung des Nachrichtenkanals 50 gelöst. Obwohl mit dem Optimierungsverfahren 100 ein Problem behandelt wird, das bei Multiprozessorsystemen auftritt, kann das Verfahren auch bei Einzelprozessorsystemen angewendet werden.
-
Benutzer, die als Benutzer 1 30A, Benutzer 2 30B, ..., Benutzer K 30K (kollektiv „Benutzer 30“) bezeichnet sind, stellen Abschnitte des pcode-Flows in dem gesamten Multiprozessorsystem dar. Tools 80, die aus einer Anwendungsprogrammier-Schnittstelle (application programming interface - API) und Helferfunktionen gebildet sind, stehen sowohl dem Nachrichtenkanal-Treiber 50 als auch den Benutzern 30 zur Verfügung.
-
Bei einigen Ausführungsformen wird bei dem Verfahren 100 ein Virtuell-Kanal-Identifizierer (virtual channel identifier - VCID) 60 jedem Benutzer (pcode-Flow) 30 zugewiesen, der den Nachrichtenkanal 20 benutzt. Virtuell-Kanal-Identifizierer 60A, 60B, ..., 60K (kollektiv „VCIDs 60“) stehen jeweils jedem Benutzer 30A, 30B, ..., 30K zur Verfügung. Jeder pcode-Flow 30 mit einem VCID 60 ist ferner in der Lage, eine Rückrufadresse zu registrieren. Rückrufadressen 40A, 40B, ..., 40K sind in 2 jeweils für Benutzer 1, 2, ..., K (kollektiv „Rückrufadressen 40“) gezeigt. Die Rückrufadresse 40 für jeden Benutzer 30 ermöglicht es dem Nachrichtenkanal-Treiber 50, im Anschluss an die Verarbeitung der Nachrichtenkanal-Transaktion für diesen Benutzer an der geeigneten Adresse zu dem pcode-Flow zurückzukehren. Jeder Benutzer 30 mit einem VCID 60 kann eine Nachrichtenkanal-Transaktion zur Verarbeitung vorlegen.
-
Bei einigen Ausführungsformen weist jeder Benutzer 30A, 30B, ..., 30K einen jeweiligen Puffer 90A, 90B, .., 90K (kollektiv „Puffer 90“) auf. Die Puffer 90 sind temporäre Speichereinrichtungen für Nachrichtenkanal-Daten, die im Anschluss an eine Nachrichtentransaktion zurückzusenden sind. Bei einigen Ausführungsformen ruft der Nachrichtenkanal-Treiber 50 die zurückgesendeten Daten in dem jeweiligen Puffer 90 ab, wenn er Nachrichtenkanal-Transaktionen verarbeitet.
-
Ferner weist bei einigen Ausführungsformen der Nachrichtenkanal-Treiber 50 eine Warteschlange 110 zum Nachverfolgen von Transaktionen, die auf eine Verarbeitung warten, auf. Wenn eine nachfolgende Transaktion verarbeitet wird, ruft der Nachrichtenkanal-Treiber die Transaktion aus der Warteschlage 110 ab. Bei einigen Ausführungsformen ist die Warteschlange 110 eine First-in-First-out-Warteschlange.
-
Es wird davon ausgegangen, dass die Benutzer 30 von 2 diejenigen pcode-Flows sind, bei denen Nachrichtenkanal-Transaktionen erfolgen sollen. Andere pcode-Flows können nicht in Nachrichtenkanal-Transaktionen involviert sein. Solchen pcode-Flows wird bei einigen Ausführungsformen somit kein VCID 60 zugewiesen. Trotzdem profitieren, wie nachstehend gezeigt ist, bei einigen Ausführungsformen pcode-Flows sowohl für Nachrichtenkanal-Transaktionen als auch Nicht-Nachrichtenkanal-Transaktionen von dem hier beschriebenen Optimierungsverfahren 100.
-
Bei einigen Ausführungsformen wird die Nachrichtenkanal-Transaktion entweder unverzüglich oder zu einem künftigen Zeitpunkt von dem Nachrichtenkanal-Treiber 50 verarbeitet. Der Nachrichtenkanal-Treiber 50 registriert ein Ereignis, das bewirkt, dass ein Kern innerhalb des prozessorbasierten Systems eine Rückruffunktion laufen lässt, wenn die Nachrichtenkanal-Transaktion beendet ist. Der Benutzer (pcode-Flow) 30, der die Transaktion vorgelegt hat, wird über die Beendigung benachrichtigt, wenn seine Rückruffunktion läuft, wodurch es dem Benutzer ermöglicht wird, weitere gewünschte Aktionen im Anschluss an die Beendigung durchzuführen.
-
3 ist ein Ablaufdiagramm mit Darstellung eines Verfahrens 200, bei dem zwei Tasks von dem Nachrichtenkanal 20 sequenziell durchgeführt werden, gemäß einigen Ausführungsformen. Die Operationen 200 von 3 werden entweder in einem einzelprozessorbasierten System oder in einem Multiprozessorsystem, wie z. B. dem System 500 von 1, durchgeführt. Das Verfahren 200 umfasst mehrere Schritte, die in Zeitintervallen, welche links von jedem Schritt in rot genannt sind, durchgeführt werden. Zwei Tasks, Task 1 und Task 2, sind durchzuführen. Die Tasks sind Teil des oben genannten pcode-Flows 30, wobei der pcode-Flow eine Nachrichtenkanal-Transaktion in einem einzelprozessorbasierten System oder in dem Multiprozessorsystem 500 ausgibt. Task 1 umfasst eine Nachrichtenkanal-Transaktion, während dies bei Task 2 nicht der Fall ist.
-
Bei denjenigen Tasks, die Nachrichtenkanal-Transaktionen umfassen, wird der Task unterteilt in 1) Aufbereitung von Daten, 2) Transaktion auf dem Nachrichtenkanal, 3) Verarbeitung der Ergebnisse des Nachrichtenkanals und 4) weitere Datenverarbeitung, die nicht nachrichtenkanalbezogen sein kann.
-
In einem ersten Zeitintervall (Zeitintervall 1) beginnt der Task 1, ein erster pcode-Flow (Benutzer) 30, (Block 200). Im Anschluss an die Datenaufbereitung (Block 202) in Zeitintervall 2 gibt der pcode-Flow 30 eine Nachrichtenkanal-Transaktion in Zeitintervall 3 (Block 204) aus und aktiviert somit den Nachrichtenkanal 20. Der erste pcode-Flow 30 wartet auf die Beendigung der Transaktion (Block 206), wobei keine weitere Verarbeitung stattfindet. Bei diesem Beispiel gibt es ein Timeout-Intervall von 100 Zeiteinheiten, und der pcode-Flow 30 ist während dieses gesamten Intervalls blockiert, was als Blockier-Transaktion bekannt ist. In einem Zeitintervall 103 werden die Ergebnisse der Nachrichtentransaktion verarbeitet (Block 208) und wird der Task 1 beendet (Block 210).
-
Der pcode-Flow 30 umfasst ferner einen zweiten Task, Task 2. Der Task 2 beginnt in Zeitintervall 106 (Block 212). Die Datenverarbeitung erfolgt in Zeitintervall 107 (Block 214), und der Task 2 wird in Zeitintervall 108 (Block 216) beendet, wobei weitere Tasks im Anschluss an die Beendigung von Task 2 durchzuführen sind.
-
4 umfasst im Gegensatz dazu dieselben zwei Tasks, die entweder auf einem einzelprozessorbasierten System oder auf einem Multiprozessorsystem, wie z. B. dem System 500 von 1, sequenziell durchgeführt werden, wobei dieses Mal das Nachrichtenkanal-Optimierungsverfahren 100 von 2 angewendet wird, gemäß einigen Ausführungsformen. Der erste Task, Task 1, ist jedoch in zwei Teile, Task 1a und Task 1b, aufgeteilt, die separat verarbeitet werden.
-
Anfangs wird der erste Teil des ersten Tasks, Task 1a, auf eine im Wesentlichen gleiche Weise verarbeitet, wie der Task 1 in 3 verarbeitet worden ist. In einem ersten Zeitintervall (Zeitintervall 1) beginnt Task 1, ein erster pcode-Flow 30 (Block 300). Im Anschluss an eine Datenaufbereitung in Zeitintervall 2 (Block 302) gibt der pcode-Flow 30 eine Nachrichtenkanal-Transaktion in Zeitintervall 3 aus (Block 304) und aktiviert somit den Nachrichtenkanal 20. Bei diesem Beispiel wird, statt dass der erste pcode-Flow 30 auf die Beendigung der Transaktion wartet (wie in Block 206 von 3), die Nachrichtenkanal-Transaktion von dem Nachrichtenkanal-Treiber 50 in Zeitintervall 4 in eine Warteschlange eingereiht (Block 306). Der Task 1a, der erste Teil von Task 1, wird in Zeitintervall 5 beendet (Block 308).
-
Wie bei dem Verfahren 200 (3) umfasst bei dem Verfahren 300 (4) der pcode-Flow 30 ferner den zweiten Task, Task 2. Der Task 2 beginnt in Zeitintervall 6 (Block 310). Die Datenverarbeitung erfolgt in Zeitintervall 7 (Block 312), und der Task 2 wird in Zeitintervall 8 beendet (Block 314), wobei weitere Tasks im Anschluss an die Beendigung von Task 2 durchgeführt werden. Es sei darauf hingewiesen, dass in 3 der Task 2 in Zeitintervall 108 beendet wird, während bei dem aktuellen Beispiel der Task 2 einhundert Zeiteinheiten früher in Zeitintervall 8 beendet wird.
-
Bei der Verarbeitung des ersten Tasks wird dann, wenn die Nachrichtenkanal-Transaktion ausgegeben wird (Block 304), die Transaktion genau wie in 3 verarbeitet. Und genau wie in 3 werden bei der Transaktion 100 Zeiteinheiten für die Verarbeitung verwendet. In 4 ist die Transaktionsverarbeitung nicht unterbrochen oder verändert worden, stattdessen wird die Transaktion von dem Nachrichtenkanal-Treiber 50 in eine Warteschlange eingereiht, wodurch ermöglicht wird, dass die Verarbeitung von Task 1a beendet wird, so dass der nächste Task, Task 2, verarbeitet werden kann.
-
Bei einigen Ausführungsformen wird dann, wenn eine Nachrichtenkanal-Transaktion, die initiiert worden ist, während der Task 1a beendet wurde, ein Hardware-Ereignis in Zeitintervall 103 erzeugt (Block 400). Der Nachrichtenkanal-Treiber 50 spricht durch Ausgeben eines Rückrufs an die Adresse des zweiten Teils von Task 1, Task 1b, in Zeitintervall 104 auf das Hardware-Ereignis an (Block 402). Die Rückrufadresse 40 für den vorgegebenen pcode-Flow (Benutzer) 30 enthält die Adresse. Der Task 1b beginnt in Zeitintervall 105 (Block 404). Da die Nachrichtenkanal-Transaktion beendet ist, wird die Ergebnisverarbeitung in Zeitintervall 106 durchgeführt (Block 406), und der Task 1b endet in Zeitintervall 107 (Block 407).
-
Es ist aufschlussreich, die Operationen 200 von 3 mit den optimierten Operationen 300, 400 von 4 zu vergleichen. In 3 werden zwei pcode-Flow-Tasks, Task 1 und Task 2, in 108 Zeitintervallen verarbeitet. In 4 werden dieselben zwei pcode-Flow-Tasks, Task 1 und Task 2, wobei der erste Task ferner in Tasks 1a und 1b unterteilt ist, in 107 Zeitintervallen mit einer Verbesserung von einem Zeitintervall verarbeitet. Ferner gibt es jedoch eine weitere Gelegenheit zur sequenziellen Verarbeitung von weiteren Tasks im Anschluss an die Beendigung von Task 2, wobei 95 Zeitintervalle zwischen dem Zeitintervall 8 und dem Zeitintervall 103 zur Verfügung stehen. Und entweder können Tasks, bei denen Nachrichtenkanal-Transaktionen ausgegeben werden (wie z. B. Task 1) oder Tasks, bei denen keine Nachrichtenkanal-Transaktionen ausgegeben werden (wie z. B. Task 2) während dieser 95 Zeitintervalle verarbeitet werden. Somit bieten die Operationen 300, 400 von 4 weitere Gelegenheiten zur effizienten Verarbeitung von Nachrichtenkanal-Transaktionen, ohne dass eine oder mehrere Transaktionen blockiert werden müssen.
-
Ferner beginnt bei einigen Ausführungsformen die Verarbeitung der Transaktionen von Task 2 bei dem Verfahren 300 viel früher als bei dem Verfahren 200. Und dadurch, dass es möglich ist, mehr Tasks sequenziell in den 95 weiteren Zeitintervallen zu verarbeiten, können die Zyklen einen funktionalen Nutzen für das System, das die Transaktionen verarbeitet, bieten. Bei einigen Ausführungsformen gibt der pcode Hunderte von Nachrichtenkanal-Transaktionen pro Millisekunde aus, so dass der potenzielle Nutzen des Verwendens der Zyklen beträchtlich sein kann.
-
Es sei daran erinnert, dass sowohl der Nachrichtenkanal-Treiber 50 als auch die Benutzer 30 Tools 80 zur Unterstützung bei der Durchführung des Optimierungsverfahrens 100 verwenden. 5 zeigt die Tools 80, die bei einigen Ausführungsformen bei dem Optimierungsverfahren 100 verwendet werden. Es gibt vier Funktionen 72, 74, 76 und 78, die als Anwendungsprogrammier-Schnittstellen (API)-Funktionen klassifiziert sind, und zwei Funktionen 82 und 84, die als Helferfunktionen angesehen werden. Funktional ist der Benutzer 30 über eine Schnittstelle (über die API-Funktionen 72, 74, 76, 78) mit dem Treiber 50 verbunden, und der Treiber ist über eine Schnittstelle mit dem Prozessor verbunden. Die API-Funktionen ermöglichen es daher den Benutzern, über den Treiber 50 auf den Prozessor zuzugreifen.
-
Bei einigen Ausführungsformen ermöglicht es die erste API-Funktion 72, ist_virtueller_Nachrichtenkanal_belegt, dem Benutzer 30 zu bestimmen, ob sein virtueller Kanal belegt oder unbelegt ist. Der VCID 60 für den Benutzer 30 wird als Eingang zu dieser Funktion 72 geliefert. Es sei daran erinnert, dass auf der Basis des VCID 60 der virtuelle Kanal 70 dem Benutzer 30 zugewiesen ist. Falls der Benutzer 30 eine Anforderung auf seinem virtuellen Kanal 70 erfasst, kann eine weitere Anforderung erst gesendet werden, wenn die erste Nachricht verarbeitet worden ist. Somit ermittelt der Benutzer 30, bevor er mit der zweiten Nachricht fortfährt, unter Verwendung der API-Funktion 72, ob sein virtueller Nachrichtenkanal 70 nicht belegt ist. Ferner verwendet, falls die Nachrichtenkanal-Anforderung eine ist, bei der Daten zurückgesendet werden, der Benutzer 30 die API-Funktion 72 zum Bestimmen, ob die Anforderung beendet worden ist, wodurch es dem Benutzer ermöglicht wird, die zurückgesendeten Daten abzurufen. Die API-Funktion 72 ist somit im Wesentlichen ein Quittierungsmechanismus zwischen dem Benutzer 30 und dem Nachrichtenkanal-Treiber 50. Die API-Funktion 72 sendet ein Lauf-/Belegt-Bit für den virtuellen Nachrichtenkanal 70 zurück, der von dem VCID 60 für den Benutzer 30 spezifiziert wird.
-
Bei einigen Ausführungsformen sendet die zweite API-Funktion 74, Nachrichtenkanal_Virtuell_Lesen, den Inhalt des virtuellen Nachrichtenkanals 70, der von dem Eingang, VCID 60, spezifiziert wird, zurück. Bei einigen Ausführungsformen wird ein 64-Bit-Nachrichtenkanal-Nutzdatenergebnis von der API-Funktion 74 zurückgesendet. Der Nachrichtenkanal-Treiber 50 sendet die Leseinformationen zu dem Puffer 90 zurück, der dem Benutzer 30 zugeordnet ist. Somit liest bei Aktivieren dieser Lesefunktion 74 der Benutzer 30 den Inhalt des Puffers 90.
-
Bei einigen Ausführungsformen ist die dritte API-Funktion 76, Nachrichtenkanal_Virtuell_Senden, das Mittel, mit dem der Benutzer 30 eine Nachricht auf dem Nachrichtenkanal 20 unter Verwendung seines virtuellen Nachrichtenkanals 70 sendet. Es sei daran erinnert, dass der Nachrichtenkanal 20 von vielen ungleichartigen pcode-Flows und Funktionen zwischen Endpunkten in dem Prozessor verwendet wird, wie z. B. zum Lesen und Schreiben von Uncore-Steuerregistern, Ausgeben von Energiemanagementanforderungen (PMReqs) sowie zum Senden von Nachrichten zu anderen Plattform-Entitäten (z. B. anderen CPUs 150, PCHs 180 in dem Multiprozessorsystem 500). Auch hier wird der VCID 60 für den Benutzer 30 als Eingang zu dieser Funktion 76 geliefert. Sobald sich die Nachricht auf dem virtuellen Nachrichtenkanal 70 befindet, ist der Nachrichtenkanal-Treiber 50 in der Lage, die Nachricht auf dem Nachrichtenkanal 30 zu verarbeiten.
-
Bei einigen Ausführungsformen ist die vierte API-Funktion 78, Nachrichtenkanal_Virtuell_Senden_PMReq, eine Spezialversion der dritten API-Funktion 76, die eine PMReq-Übertragung verarbeitet. Wie bei den anderen API-Funktionen wird der VCID 60 für den Benutzer 30 als Eingang zu dieser Funktion 78 geliefert. PMReq, kurz für Power Management Request (Energiemanagementanforderung), ist ein Spezialtyp einer Transaktion, die von dem QPI-Bus, der eine Zwischenverbindung zwischen CPUs ist, verwendet wird ( 1).
-
Während sowohl die Benutzer 30 als auch der Nachrichtenkanal-Treiber 50 die oben genannten API-Funktionen anwenden, wendet bei einigen Ausführungsformen nur der Treiber 50 die Helferfunktionen 82 und 84 an. Die Helferfunktionen ermöglichen eine einfache Bewegung von Daten zwischen den virtuellen Kanälen 70 und dem physikalischen Nachrichtenkanal 20. Die erste Helferfunktion, Nachrichtenkanal_Senden_zu_Physikalisch 82, ermöglicht es dem Nachrichtenkanal-Treiber 50, Daten zu dem physikalischen Nachrichtenkanal 20 zu senden. Die zweite Helferfunktion, Nachrichtenkanal_Abfragen_Physikalisch_mit_Timeout 84, ermöglicht es dem Nachrichtenkanal-Treiber 50, den physikalischen Nachrichtenkanal bezüglich der Beendigung einer Operation abzufragen, und umfasst ein Timeout.
-
Bei einigen Ausführungsformen registriert der Nachrichtenkanal-Treiber 50 ein Ereignis, das bewirkt, dass ein Kern innerhalb des einzelprozessorbasierten Systems oder des Multiprozessorsystems eine Rückruffunktion laufen lässt, wenn die Nachrichtenkanal-Transaktion beendet ist. Das Ereignis ist ein Hardware-Ereignis, wie z. B. ein Interrupt, das anzeigt, dass der Nachrichtenkanal 20 nicht mehr belegt ist, was bedeutet, dass das Letzte, das der Treiber in den Nachrichtenkanal gegeben hat, beendet ist.
-
Bei einigen Ausführungsformen gibt im Auftrag eines Benutzers (pcode-Flows) 30 der Nachrichtenkanal-Treiber 50 eine Mitteilung aus den zugewiesenen virtuellen Kanälen 70 des Benutzers in den Nachrichtenkanal 20. Der Nachrichtenkanal-Treiber 50 versteht, ob die Nachricht bedeutet, dass Daten zurückzusenden sind oder nicht. Wenn Daten zurückzusenden sind, ruft der Nachrichtenkanal-Treiber 50 die Daten ab und gibt sie in den Puffer 90, der für den Benutzer 30 zweckbestimmt ist. Im Anschluss an das Abrufen durch den Treiber 50 wendet der Benutzer 30 die API-Lesefunktion 74 an, um den Inhalt des Puffers 90 abzurufen.
-
Sobald die Verarbeitung einer Nachrichtenkanal-Transaktion im Auftrag eines Benutzers beendet ist, kann der Nachrichtenkanal-Treiber 50 zum „Verbinden“ eines weiteren virtuellen Kanals 70 mit dem Nachrichtenkanal 20 im Auftrag eines anderen Benutzers 30 weitergehen.
-
6 und 7 sind Ablaufdiagramme mit Darstellung von Operationen des Nachrichtenkanal-Optimierungsverfahrens 100 bei Verarbeitung jeweils einer Sende-Operation und einer Lese-Operation gemäß einigen Ausführungsformen. 6 zeigt eine Sende-Operation eines der Benutzer 30 entweder eines einzelprozessorbasierten Systems oder eines Multiprozessorsystems, wie z. B. des Multiprozessorsystems 500 von 1, während 7 eine Lese-Operation zeigt.
-
Zuerst beschreibt 6 die Sende-Operation. Bevor der Benutzer 30 eine Transaktion auf dem Nachrichtenkanal 20 ausgeben kann, muss bei einigen Ausführungsformen der dem Benutzer zugewiesene virtuelle Nachrichtenkanal 70 zur Verfügung stehen. Somit gibt der Benutzer die erste API-Funktion 72 aus, um zu bestimmen, ob der virtuelle Nachrichtenkanal 70 zur Verfügung steht (Block 102). Sobald dieser zur Verfügung steht, gibt der Benutzer 30 eine API-Sende-Funktion, entweder die allgemeine API-Sende-Funktion 76 oder die spezialisierte API-Sende-PMReq-Funktion 78 aus (Block 104). Der Benutzer 30 registriert ferner eine Rückrufadresse (Block 106), die der Nachrichtenkanal-Treiber 50 zum Zurücksenden zu einer vorbestimmten Adresse des Benutzers verwendet (Block 106). An diesem Punkt wird die Nachrichtenkanal(Sende)-Transaktion von dem Nachrichtenkanal-Treiber 50 in eine Warteschlange eingereiht (Block 108). Dadurch wird der Benutzer 30 frei, mit einer anderen Transaktionsverarbeitung fortzufahren.
-
Wenn die Sende-Transaktion von dem Benutzer 30 ausgegeben wird, kann der Nachrichtenkanal 20 nicht zur Verfügung stehen. Der pcode eines typischen Multiprozessorsystems verwendet den Nachrichtenkanal ziemlich häufig, von Hunderten bis Tausenden von Malen pro Millisekunde. Somit wird die Sende-Transaktion erst verarbeitet, wenn der Nachrichtenkanal 20 nicht belegt ist (Block 110). Sobald der Nachrichtenkanal 20 zur Verfügung steht, wird der Nachrichtenkanal-Treiber 50 durch ein Hardware-Ereignis, wie z. B. ein Interrupt, darüber benachrichtigt, dass der Nachrichtenkanal zur Verfügung steht.
-
Der Nachrichtenkanal-Treiber 50 verarbeitet jedoch Virtuell-Nachrichtenkanal-Transaktionen für eine Anzahl von Benutzern. Sobald der Nachrichtenkanal 20 zur Verfügung steht und sobald sich der Benutzer ganz vorn in der Warteschlange 110 des Nachrichtenkanal-Treibers befindet, sendet der Nachrichtenkanal-Treiber 50 die Nachrichtenkanal-Transaktion aus dem virtuellen Kanal 70 des Benutzers zu dem Nachrichtenkanal 20 (Block 112). Sobald sie sich in dem Nachrichtenkanal 20 befindet, wird die Nachrichtenkanal-Transaktion verarbeitet (Block 114). Der Nachrichtenkanal-Treiber 50 registriert dann ein Ereignis. Dieses Ereignis bewirkt, dass der Kern des einzelprozessorbasierten Systems oder des Multiprozessorsystems die Rückruffunktion zu der Rückrufadresse 40 des Benutzers 30 laufen lässt (Block 116). Der Benutzer 30 ist somit in der Lage, die Sende-Transaktion zu beenden (Block 118).
-
7 zeigt im Wesentlichen gleiche Operationen, wobei dieses Mal der Benutzer 30 eine Lese-Operation zu dem Nachrichtenkanal 20 überträgt. Auch hier stellt der Benutzer 30 zuerst sicher, dass der virtuelle Kanal 70 zur Verfügung steht (Block 152). Sobald dieser zur Verfügung steht, gibt der Benutzer 30 die API-Lese-Funktion 74 an seinen virtuellen Nachrichtenkanal 70 aus (Block 154). Der Benutzer registriert ferner seine Rückrufadresse (Block 156), so dass der Nachrichtenkanal-Treiber 50 in der Lage ist, zu dem Benutzer-pcode-Flow 30 zurückzukehren, sobald die Nachrichtenkanal-Transaktion beendet ist. Der Nachrichtenkanal-Treiber 50 reiht die Transaktion in eine Warteschlange ein (Block 158).
-
Sobald der Nachrichtenkanal 20 zur Verfügung steht (Block 160) und sobald sich der Benutzer ganz vorn in der Warteschlange 110 des Nachrichtenkanal-Treibers befindet, sendet der Nachrichtenkanal-Treiber 50 die Nachrichtenkanal-Transaktion aus dem virtuellen Kanal 70 des Benutzers zu dem Nachrichtenkanal 20 (Block 162). Sobald sie sich in dem Nachrichtenkanal 20 befindet, wird die Nachrichtenkanal-Transaktion verarbeitet (Block 164). Der Nachrichtenkanal-Treiber 50 registriert dann ein Ereignis. Dieses bewirkt, dass der Kern des einzelprozessorbasierten Systems oder des Multiprozessorsystems die Rückruffunktion zu der Rückrufadresse 40 des Benutzers 30 laufen lässt (Block 166). Da die Transaktion eine Lese-Transaktion ist, gibt der Nachrichtenkanal-Treiber 50 den Lese-Inhalt in den Puffer 90 des Benutzers 30. Der Benutzer 30 ruft somit den Inhalt des Puffers 90 ab (Block 168) und beendet die Lese-Transaktion (Block 170).
-
Das Nachrichtenkanal-Optimierungsverfahren und -system 100 ermöglicht somit einen Multiflow-Zugriff auf die Nachrichtenkanal-Infrastruktur innerhalb einer CPU eines einzelprozessorbasierten Systems oder eines Multiprozessorsystems. Der Benutzer verwendet einen virtuellen Kanal zum Vorlegen einer Nachrichtenkanal-Transaktion, wobei der Nachrichtenkanal-Treiber die Transaktion „hinter den Kulissen“ verarbeitet. Jede Transaktion wird entweder unmittelbar oder zu einem künftigen Zeitpunkt von dem Nachrichtenkanal-Treiber verarbeitet. Tasks, die Nachrichtenkanal-Transaktionen sowie Nicht-Nachrichtenkanal-Transaktionen umfassen, werden bei einigen Ausführungsformen effizienter verarbeitet.
