DE102006046717A1

DE102006046717A1 - Dynamisch migrierende Kanäle

Info

Publication number: DE102006046717A1
Application number: DE102006046717A
Authority: DE
Inventors: Gautham Hillsboro Chinya; Robert Cupertino Geva; Robert Hillsboro Knight; Hong Santa Clara Wang; Xiang Beaverton Zou
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2005-09-30
Filing date: 2006-10-02
Publication date: 2007-05-03
Anticipated expiration: 2026-10-03
Also published as: CN101013378B; US20070079020A1; US7631125B2; US8296552B2; DE102006046717B4; US8001364B2; US20110258632A1; US20100042765A1; CN101013378A

Abstract

Eine Ausführungsform der vorliegenden Erfindung umfasst ein Verfahren zur Ermittlung einer relativen Priorität eines ersten und eines zweiten Agenten und zur Zuweisung des ersten Agenten zu einem ersten Kanal und des zweiten Agenten zu einem zweiten Kanal gemäß ihrer relativen Priorität. Abhängig vom aktuell programmierten Zustand der Kanäle kann in mindestens einem der Kanäle gespeicherte Information anhand der Zuweisung dynamisch zu einem anderen Kanal migriert werden. Weitere Ausführungsformen werden beschrieben und beansprucht.

Description

Hintergrund
Ausführungsformen der vorliegenden Erfindung beziehen sich auf Computersysteme und insbesondere auf die effektive Nutzung eines derartigen Systems.

Computersysteme führen verschiedene Softwareprogramme aus, unter Nutzung verschiedener Hardware-Ressourcen des Systems, einschließlich eines Prozessors, eines Speichers und weiterer derartiger Komponenten. Ein Prozessor umfasst wiederum verschiedene Ressourcen einschließlich eines oder mehrerer Ausführungskerne, Cache-Speicher, Hardware-Register u. ä. Daneben enthalten bestimmte Prozessoren auch Zähler für die Hardware-Leistung zur Zählung der im Laufe der Programmausführung auftretenden Ereignisse und Aktivitäten. Bestimmte Prozessoren enthalten zum Beispiel Zähler für Speicherzugriffe, Cache-Fehltreffer, ausgeführte Anweisungen und dergleichen. Daneben kann die Leistungsüberwachung auch mittels Software erfolgen, zur Überwachung der Ausführung eines oder mehrerer Softwareprogramme.

Gemeinsam können derartige Zähler und Überwachungseinrichtungen mindestens gemäß zwei Nutzungsmodellen eingesetzt werden. Zum einen können sie bei der Kompilierung und anderen Optimierungsvorgängen zur Verbesserung der Code-Ausführung basierend auf im Laufe der Programmausführung erhaltenen Profilinformationen verwendet werden. Zum anderen können nach einem Ereignis in einem Zähler oder einer Überwachungseinrichtung während der Programmausführung ein oder mehrere Hilfsprozesse (Helper Threads) aufgerufen werden. Derartige Hilfsprozesse sind Softwareroutinen, die von einem Aufrufprogramm zum Verbessern der Ausführung aufgerufen werden, wie zum Beispiel dazu, Daten vorab aus dem Speicher abzurufen oder eine andere derartige Tätigkeit zu übernehmen, um die Ausführung des Programms zu verbessern.

Häufig werden diese Ressourcen ineffizient genutzt, und darüber hinaus kann die Nutzung derartiger Ressourcen in den verschiedenen Nutzungsmodellen im Konflikt stehen. Da her besteht ein Bedarf an verbesserten Wegen für Erhalt und Nutzung von Überwachungseinrichtungen und Leistungsinformationen zur Verwendung in diesen verschiedenen Nutzungsmodellen.

Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Blockdiagramm einer Hardware-Implementierung von mehreren Kanälen gemäß einer Ausführungsform der vorliegenden Erfindung.
3 ist ein Flussdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Flussdiagramm eines dynamischen Kanalmigrations-Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist ein Beispiel für die Kanalzuweisung vor und nach der dynamischen Kanalmigration gemäß einer Ausführungsform der vorliegenden Erfindung.
6 ist weiteres Beispiel für die Kanalzuweisung vor und nach der dynamischen Kanalmigration gemäß einer Ausführungsform der vorliegenden Erfindung.
7 ist ein Flussdiagramm eines Verfahrens für den Einsatz programmierter Kanäle gemäß einer Ausführungsform der vorliegenden Erfindung.
8 ist ein Blockdiagramm eines aus mehreren Prozessoren bestehenden Systems (Multiprozessor-System) gemäß einer Ausführungsform der vorliegenden Erfindung.
Detaillierte Beschreibung
1 zeigt ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform der vorliegenden Erfindung. Wie 1 zeigt, kann der Prozessor 10 verschiedene Ressourcen umfassen. In manchen Ausführungsformen kann der Prozessor 10 ein Chip-Multiprozessor (CMP) oder eine sonstige Multiprozessoreinheit sein. Wie 1 zeigt, kann ein erster Kern 20 und ein zweiter Kern 30 zur Ausführung von Anweisungen verschiedener Software-Threads verwendet werden. Wie 1 außerdem zeigt, umfasst der erste Kern 20 eine Überwachungseinrichtung 40, die zur Verwaltung von Ressourcen und der Steuerung einer Anzahl von Kanälen 50a-50d des Kerns verwendet werden können. Des Weiteren kann der erste Kern 20 weiterhin Ausführungsressourcen 22 umfassen, die zum Beispiel eine Pipeline des Kerns und andere Ausführungseinheiten umfassen können. Des Weiteren kann der erste Kern 20 eine Anzahl von Leistungszählern 45 umfassen, gekoppelt mit den Ausführungsressourcen 22, die zur Zählung verschiedener Aktivitäten oder Ereignisse in diesen Ressourcen verwendet werden können. Auf diese Weise können die Leistungszähler 45 bestimmte Zustände und/oder Zählstände erfassen sowie verschiedene Ereignisse in Architektur und/oder Mikroarchitektur überwachen. Die Leistungszähler 45 können mit einer Überwachungseinrichtung 40 kommunizieren und ihr zum Beispiel die Zählstände übermitteln.
Die Überwachungseinrichtung 40 kann verschiedene programmierbare Logiken, Software und/oder Firmware zum Verfolgen der Aktivitäten der Leistungszähler 45 und der Kanäle 50a-50d umfassen. Die Kanäle 50a-50d können in einer Ausführungsform register-basierte Speichermedien sein. Ein Kanal ist ein Architekturzustand, der eine Spezifikation und Ereignisinformation für ein Szenario umfasst, wie nachstehend beschrieben. In verschiedenen Ausführungsformen kann ein Kern einen oder mehrere Kanäle umfassen. Es kann einen oder mehrere Kanäle pro Software-Thread geben, und Kanäle können per Software-Thread virtualisiert werden. Kanäle 50a-50d können von einer Überwachungseinrichtung 40 für verschiedene Nutzungsmodelle programmiert werden, einschließlich profilgesteuerter Optimierung (PGO) oder in Verbindung mit gesteigerter Programmleistung mittels Hilfsprozessen u. ä.
Obgleich die Erfindung in der in 1 dargestellten Ausführungsform vier derartige Kanäle umfasst, soll betont werden, dass der Rahmen der vorliegenden Erfindung nicht darauf begrenzt ist und andere Ausführungsformen mit einer geringeren oder höheren Anzahl von Kanälen existieren können. Obgleich Kanäle zur leichteren Illustration nur im ersten Kern 20 gezeigt werden, können sie in mehreren Prozessorkernen vorhanden sein. Den Kanälen 50a-50d kann eine Yield-Anzeige 52 zugeordnet sein. In verschiedenen Ausführungsformen kann die Yield-Anzeige 52 als Sperre fungieren, um das Auftreten eines oder mehrerer Yield- Ereignisse (im Folgenden eingehender erläutert) zu verhindern, während die Yield-Anzeige 52 zum Beispiel in einem vorgegebenen Zustand ist.
1 zeigt weiterhin, dass ein Prozessor 10 zusätzliche Komponenten umfassen kann, wie eine zwischen dem ersten Kern 20 und dem zweiten Kern 30 gekoppelte globale Warteschlange 35. Die globale Warteschlange 35 kann zur Bereitstellung verschiedener Steuerfunktionen für den Prozessor 10 verwendet werden. So kann die globale Warteschlange 35 zum Beispiel einen Snoop-Filter oder sonstige Logik zur Verarbeitung der Interaktionen zwischen mehreren Kernen eines Prozessors 10 umfassen. Wie 1 außerdem zeigt, kann ein Cache-Speicher 36 als Last Level Cache (LLC) fungieren. Des Weiteren kann ein Prozessor 10 einen Speichersteuerungs-Hub (Memory Controller Hub = MCH) 38 zur Steuerung der Interaktion zwischen einem Prozessor 10 und einem an ihn angeschlossen Speicher wie zum Beispiel einen dynamischen Direktzugriffsspeicher (DRAM) umfassen (nicht in 1 dargestellt). Obgleich der Prozessor in 1 mit begrenzten Komponenten gezeigt ist, muss betont werden, dass ein Prozessor 10 in verschiedenen Ausführungsformen andere Komponenten und Ressourcen umfassen kann, wie zusätzliche Cache-Speicher, Standard-Registersätze, Eingangs- und Ausgangsschnittstellen (I/O) u. ä.. Außerdem muss betont werden, dass zumindest einige der in 1 gezeigten Komponenten Hardware- oder Firmware-Ressourcen oder eine beliebige Kombination von Hardware, Software und/oder Firmware umfassen können.
2 zeigt ein Blockdiagramm einer Hardware-Implementierung mehrerer Kanäle gemäß einer Ausführungsform der vorliegenden Erfindung. Wie 2 zeigt, können die Kanäle 50a-50d aus der Sicht der Software jeweils den Kanälen 0-3 entsprechen. In der in 2 dargestellten Ausführungsform können die Kanalkennungen (IDs) 0-3 einen für ein bestimmtes Szenario programmierten Kanal bezeichnen und können der relativen Priorität dieses Kanals entsprechen. In verschiedenen Ausführungsformen kann eine Kanalkennung auch eine Sequenz (d.h. Priorität) von auszuführenden Dienstroutinen kennzeichnen, wenn mehrere Szenarios von der gleichen Anweisung ausgelöst werden, obgleich der Rahmen der vorliegenden Erfindung nicht darauf begrenzt ist. Wie in 2 gezeigt ist, enthält jeder Kanal, wenn er programmiert ist, ein Szenario-Segment 55, ein Dienstroutinensegment 60, ein Segment 65 für Yield-Ereignisanforderungen (Yield Event Request = YER), ein Aktionssegment 70 sowie ein Valid-Segment 75. Obgleich sie in der in 2 dargestellten Ausführungsform in dieser spezifischen Implementierung gezeigt wird, muss betont werden, dass in anderen Ausführungsformen zusätzliche oder andere Informationen in programmierten Kanälen gespeichert werden können.
Ein Szenario definiert eine zusammengesetzte Bedingung. Mit anderen Worten definiert ein Szenario ein oder mehrere Leistungsereignisse oder -zustände, die bei der Ausführung von Anweisungen in einem Prozessor auftreten können. Diese Ereignisse oder Zustände, bei denen es sich um ein einziges Ereignis oder eine Reihe von Ereignissen oder Zuständen handeln kann, können in verschiedenen Ausführungsformen Ereignisse in der Architektur, der Mikroarchitektur oder eine Kombination beider sein. Ein Szenario umfasst eine auslösende Bedingung, wie das Auftreten mehrerer Bedingungen während der Progammausführung. Obwohl diese verschiedenen Bedingungen variieren können, können sie in manchen Ausführungsformen mit Anzeigen für einen geringen Fortschritt und/oder anderen architekturtechnischen oder strukturellen Details zum Beispiel von in Ausführungsressourcen 22 auftretenden Vorgängen verbunden sein. Das Szenario kann außerdem auch definieren, dass Prozessorzustandsdaten abrufbereit sind, die den Zustand des Prozessors zum Auslösezeitpunkt wiedergeben. In verschiedenen Ausführungsformen können Szenarios in einen Prozessor festcodiert sein. In diesen Ausführungsformen können Szenarios, die von einem bestimmten Prozessor unterstützt werden, über eine Identifizierungsanweisung entdeckt werden (z.B. die CPLTID-Anweisung in einer Intel^TM x86 Instruction Set Architektur (ISA)).
Eine Dienstroutine ist eine Szenario-spezifische Funktion, die ausgeführt wird, wenn ein Yield-Ereignis auftritt. Wie in 2 gezeigt, kann jeder Kanal ein Dienstroutinensegment 60 umfassen, das die Adresse der zugehörigen Dienstroutine enthält. Ein Yield-Ereignis ist ein Ereignis in der Architektur, das die Ausführung eines in Ausführung begriffenen Ausführungsstroms an eine dem Szenario zugehörige Dienstroutine überträgt. In verschiedenen Ausführungsformen tritt ein Yield-Ereignis auf, wenn die Auslösebedingung eines Szenarios erfüllt wird. In verschiedenen Ausführungsformen kann die Überwachungseinrichtung die Ausführung einer Dienstroutine nach dem Auftreten eines Yield-Ereignisses auslösen. Nach Beenden der Dienstroutine wird der zuvor ausgeführte Ausführungsstrom weiter ausgeführt. Die im YER-Segment 65 gespeicherte Yield-Ereignisanforderung (yield event request, YER) ist ein Bit pro Kanal, das anzeigt, dass das dem Kanal zugehörige Szenario ausgelöst wurde und dass ein Yield-Ereignis ansteht. Die im Aktionssegment 70 gespeicherten Aktionsbits eines Kanals definieren das Verhalten des Kanals beim Auslösen des zugehörigen Szenarios.
Schließlich kann ein Valid-Segment 75 den Progammierzustand des zugehörigen Kanals anzeigen (d.h. anzeigen, ob der Kanal programmiert worden ist).
2 zeigt weiterhin eine den Kanälen 50a-50d zugehörige Yield-Anzeige 52, hier auch als Yield-Block-Bit (YBB) bezeichnet. Die Yield-Anzeige 52 kann eine Sperre pro Software-Thread darstellen. Ist die Yield-Anzeige 52 gesetzt, so werden sämtliche diesem Software-Thread zugehörigen Kanäle eingefroren. Das bedeutet, dass, wenn die Yield-Anzeige 52 gesetzt ist, die zugehörigen Kanäle keine Ausbeute (Yield) liefern können und auch ihre zugehörige(n) Szenario-Auslösebedingung(en) nicht ausgewertet (z. B. gezählt) werden kann (können).
Unter Bezugnahme auf 3 ist ein Blockdiagamm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt, Wie in 3 gezeigt, kann ein Verfahren 100 zur Programmierung eines Kanals gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden. Wie vorstehend beschrieben, kann in verschiedenen Ausführungsformen eine Überwachungseinrichtung den Betrieb der Kanäle, einschließlich einer Progammierung der Kanäle, steuern. Wie in 3 gezeigt, kann ein Verfahren 100 damit beginnen, zu ermitteln, ob es einen verfügbaren Kanal gibt (Block 120). In manchen Ausführungsformen gilt ein Kanal als verfügbar, wenn sein Valid-Bit frei ist. In manchen Implementierungen kann eine Routine ausgeführt werden, um das Valid-Bit von jedem Kanals zu lesen. Die Anzahl der in einem bestimmten Prozessor vorhandenen Kanäle kann zum Beispiel über eine CPUID-Anweisung ermittelt werden. Die nachstehende Tabelle 1 zeigt ein Beispiel einer Code-Sequenz zur Ermittlung eines verfügbaren Kanals in einer Ausführungsform der vorliegenden Erfindung.
Tabelle 1
Wie Tabelle 1 zeigt, kann zuerst ein Register (d.h. ECX) eingerichtet werden und eine An- weisung zum Lesen des aktuellen Kanals (d.h. EREAD) ausgeführt werden, um zu ermitteln, ob der aktuelle Kanal verfügbar ist. Wenn also das Valid-Bit des aktuellen Kanals null ist, so ist der aktuelle Kanal verfügbar, und die in Tabelle 1 aufgeführte Routine wird beendet und der Wert des verfügbaren Kanals ausgegeben. Dabei ist zu beachten, dass durch Setzen des Abgleichbits auf null die Information zum Prozessorzustand während der Routine in Tabelle 1 nicht geschrieben wird.
Zurück zu 3: Wird bei Raute 120 ermittelt, dass es keinen verfügbaren Kanal gibt, so kann die Steuerung zum Block 125 fortschreiten. Wird kein verfügbarer Kanal gefunden, so wird in bestimmten Ausführungsformen der Entität, die diese Ressource nutzen will, eine Meldung (zum Beispiel eine Fehlermeldung) geschickt (Block 125). Wird dagegen bei Raute 120 ermittelt, dass es einen verfügbaren Kanal gibt, so kann die weitere Steuerung zum Block 130 übergehen. Dort können bei Bedarf ein oder mehrere Kanäle dynamisch migriert werden (Block 130). In einer Umgebung mit mehreren Kanälen kann ein oder mehrere Szenario(s) je nach Kanalpriorität zu einem anderen Kanal verschoben werden, was hier als dynamische Kanalmigration (Dynamic Channel Migration = DCM) bezeichnet wird. Verschiedene DCM-Ausführungsformen werden nachstehend ausführlich erläutert.
Wie 3 weiterhin zeigt, kann der gewählte Kanal nach der dynamischen Kanalmigration programmiert werden (Block 140). Bei der Programmierung eines Kanals können verschiedene Informationen in dem Kanal gespeichert werden, der zu dem anfordernden Agenten als zugehörig gewählt wird. So kann ein Software-Agent beispielsweise anfordern, dass ein Kanal mit einem bestimmten Szenario programmiert wird. Des Weiteren kann ein Agent anfordern, dass nach einem Yield-Ereignis gemäß dem Szenario ein an einer bestimmten Adresse befindliches (im Kanal gespeichertes) Dienstbedienprogramm ausgeführt werden soll. Zusätzlich können ein oder mehrere Aktionsbits in dem Kanal gespeichert werden.
Schließlich kann nach der Programmierung eines Kanals das Valid-Bit gesetzt werden, um anzuzeigen, dass der Kanal programmiert wurde (Block 150). In manchen Ausführungsformen kann das Valid-Bit während der Programmierung gesetzt werden (z. B. über eine einzige Anweisung, die den Kanal programmiert und das Valid-Bit setzt). Obgleich sie in der in 3 dargestellten Ausführungsform in dieser spezifischen Implementierung gezeigt wird, muss betont werden, dass die Programmierung der Kanäle in anderen Ausführungsformen anders durchgeführt werden kann.
Die dynamische Kanalmigration ermöglicht das Verschieben von Szenarios von einem Kanal zu einem anderen falls erwünscht. Es wird angenommen, eine bestimmte Implementierung unterstützt zwei Kanäle, einen Kanal 0 und einen Kanal 1, wobei Kanal 0 die höchste Priorität hat. Weiterhin wird angenommen, dass Kanal 0 derzeit genutzt wird (d.h. sein Valid-Bit gesetzt ist) und dass Kanal 1 verfügbar ist (d.h. sein Valid-Bit frei ist). Wenn eine Überwachungseinrichtung ermittelt, dass ein neues Szenario in den Kanal mit der höchsten Priorität programmiert werden soll und dass das neue Szenario keine Probleme an dem Szenario hervorruft, das derzeit in den Kanal mit der höchsten Priorität programmiert ist, wenn es in einen Kanal mit niedrigerer Priorität verschoben wird, so kann eine dynamische Kanalmigration stattfinden. So kann zum Beispiel die Information des gegenwärtig in Kanal 0 programmierten Szenarios gelesen und dann in Kanal 1 umprogrammiert werden.
Das in der nachstehenden Tabelle 2 aufgeführte Beispiel einer Codesequenz stellt ein Beispiel für eine dynamische Kanalmigration von Kanal 0 zu Kanal 1 dar. Insbesondere zeigt Tabelle 2, dass eine Anweisung (d.h. EREAD) ausgeführt wird, um den Zustand von Kanal 0 abzufragen. Danach wird ein Register modifiziert, in dem die Kennung für den Kanal gespeichert ist. Insbesondere wird die Kanalkennung modifiziert und vom Wert null zum Wert eins geändert. Dann wird eine Anweisung (d.h. EMONITOR) ausgeführt, um Kanal 1 mit dem zuvor in Kanal 0 gespeicherten Szenario zu programmieren. Entsprechend wird die in Kanal 0 gelesene Information in Kanal 1 geschrieben. Dabei ist zu beachten, dass in manchen Ausfüh rungsformen das Valid-Bit von Kanal 0 nicht gelöscht zu werden braucht, da bekannt ist, dass Kanal 0 mit einem neuen Szenario höherer Priorität programmiert werden wird.
Tabelle 2
Ein dynamisches Auftreten einer Ausführungsanweisung kann potenzielle Yield-Ereignisse in mehreren Kanälen auslösen und in diesem Fall kann jedes Ereignis bearbeitet werden. In verschiedenen Ausführungsformen können Yield-Ereignisse gemäß der Rangfolge der Kanalprioritäten verarbeitet werden. Obgleich eine Kanalpriorität viele unterschiedliche Formen annehmen kann, kann in einer der Ausführungsformen die Priorität auf der Reihenfolge der Kanäle basieren, d.h. ein Kanal null hat eine höchste Priorität, ein Kanal eins hat eine nächst höhere Priorität usw.
Diese Kanäle können potenziell über verschiedene nicht koordinierte Software-Agenten wie Hilfsprozesse, profilgesteuerte Optimierung (PGO), Speicherbereinigung u. ä. programmiert werden. Sich ausschließlich auf die Kanalpriorität zu verlassen, kann auf Anwendungsprogrammebene möglicherweise Probleme verursachen, da bestimmte Software-Agenten den Zustand, der später für andere Software-Agenten sichtbar wird, ändern können. Wird zum Beispiel ein Szenario bezüglich eines Hilfsprozesses in einem Kanal höherer Priorität programmiert und daher zuerst bearbeitet, so werden wahrscheinlich darauf folgende Yield-Ereignisse aktiviert, wie nachstehend beschrieben. Steht zum Beispiel gleichzeitig ein Yield-Ereignis für einen PGO-Client an, so tritt nach der Aktivierung durch den Hilfsprozess- Client ein Yield-Ereignis auf. Dann wird das Yield-Ereignis vom Yield-Ereignis-Bedienprogramm des Hilfsprozesses bearbeitet und nicht wie erwartet vom PGO-Client.
Die verschiedenen Agenten, die die Kanäle benutzen, können auf Anwendungsebene in Echtzeit über eine Überwachungseinrichtung koordiniert werden. Entsprechend steuert in verschiedenen Ausführungsformen die Überwachungseinrichtung, welcher Kanal welchem Agenten dient, so dass die Kanalpriorität der jedem Agenten zugewiesenen Priorität entsprechen kann. Verschiedene Arten der Implementierung dynamischer Kanalmigration zur Erfüllung dieser Aufgabe können in verschiedenen Ausführungsformen angewendet werden.
4 zeigt ein Flussdiagramm einer dynamischen Kanalmigration gemäß einer Ausführungsform der vorliegenden Erfindung. Wie 4 zeigt, kann das Verfahren 200 mit dem Empfang der Anforderung eines Kanals von einem Agenten beginnen (Block 210). Zum Beispiel können verschiedene Software-Agenten die Programmierung eines Kanals mit verschiedenen Zustandsinformationen wie verschiedene Leistungszählwerte, Prozessorereignisse oder ähnlichem anstreben. In manchen Ausführungsformen kann die Anforderung des Agenten von einer Überwachungseinrichtung wie einem übergeordneten Programm, zum Beispiel einer Ressourcenverwaltung, empfangen werden.
4 zeigt weiterhin, dass die Überwachungseinrichtung oder eine andere Prozessorressource ein zum Software-Agent zugehöriges Szenario einem bestimmten Kanal zuweisen kann (Block 220). Wie nachstehend weiter erörtert, können verschiedene Methoden zur Auswahl eines verfügbaren Kanals implementiert werden. Nach der Zuweisung kann der Kanal mit dem zugehörigen Szenario programmiert werden. Obgleich dies in 4 nicht dargestellt ist, kann ein normaler Betrieb nach der Programmierung wieder aufgenommen werden. Unter Bezugnahme auf 4 kann allerdings ermittelt werden, ob unmittelbar oder zu einem späteren Zeitpunkt nach der Programmierung eines ersten Kanals ein oder mehrere Anforderungen für einen Kanal empfangen wurden (Raute 230). Ist dies nicht der Fall, so endet das Verfahren 200 und der Normalbetrieb wird wieder aufgenommen.
Wird statt dessen bei Raute 230 ermittelt, dass zusätzliche Kanäle angefordert wurden, so kann danach ermittelt werden, ob ein neuer einen Kanal anfordernder Agent eine höhere Priorität hat als der (die) Agent(en), dem (denen) zuvor ein Kanal (Kanäle) zugewiesen wurde(n) (Raute 240). Bei dieser Ermittlung kann auch die relative Priorität des (der) derzeit pro grammierten Kanals (Kanäle) verglichen zur Priorität eines oder mehrerer verfügbarer Kanäle berücksichtigt werden.
Hat der neue Agent eine niedrigere Priorität, so kann ein von einem derartigen Agenten mit niedrigerer Priorität angefordertes Szenario einem Kanal mit niedrigerer Priorität zugewiesen und der Kanal entsprechend programmiert werden (Block 250). Wird statt dessen bei Raute 240 ermittelt, dass der neue Agent eine höhere Priorität hat als der dem gegenwärtig programmierten Kanal zugehörige Agent, so können die Kanäle gemäß der relativen Priorität der Agenten und der relativen Priorität der Kanäle dynamisch umkonfiguriert werden (Block 260). Nach einer derartigen dynamischen Rekonfiguration kann die Steuerung wie vorstehend beschrieben zum Block 250 übergehen. Wird die DCM während einer Dienstroutine ausgeführt, so können andere teilweise ausgeführten oder anstehenden Dienstroutinen bei der Umprogrammierung ihrer Kanäle die falsche Kanalkennung verwenden. Daher sollte die DCM im Allgemeinen nicht während einer Dienstroutine ausgeführt werden.
Die dynamische Kanalmigration kann in einer Ausführungsform wie folgt ablaufen: Wird ein Agent mit niedriger Priorität zuerst mit einer Überwachungseinrichtung registriert, so kann ihm standardmäßig ein Kanal mit der höchsten Priorität zugewiesen werden. Fordert dann später ein Agent mit höherer Priorität einen Kanal an, so kann die Überwachungseinrichtung den Agenten mit niedrigerer Priorität zu einem Kanal mit niedrigerer Priorität migrieren und somit dem Agenten mit höherer Priorität den Kanal mit höherer Priorität verfügbar machen. Dadurch stellt die Überwachungseinrichtung sicher, dass der Agent mit höherer Priorität zuerst bearbeitet wird und verhindert das Problem, dass sich ein Agent mit niedrigerer Priorität abträglich auf den vom Kanal mit höherer Priorität sichtbaren Zustand auswirkt. In anderen Ausführungsformen kann jedoch ein gegenwärtig programmierter Kanal dynamisch zu einem Kanal mit höherer Priorität migriert werden, wenn ein neuer Agent mit niedrigerer Priorität die Programmierung eines Kanals anfordert.
In verschiedenen Ausführungsformen kann ein Szenario nur dann zu einem Kanal niedrigerer Priorität übertragen werden, wenn das Szenario keine unerwünschten Nebenwirkungen durch das Übertragen erleidet. Das heißt, dass das Verhalten des Szenarios oder seiner in den Kanal mit höherer Priorität programmierten Dienstroutine gewöhnlich bestimmt, wie die Szenarios niedrigerer Priorität beeinflusst werden. Wenn durch einen Wechsel der Kanalpriorität zum Beispiel ein Szenario eine andere Anzahl an Ereignissen hervorbringt oder von dem Szenario erfasste Daten möglicherweise korrumpiert oder verändert werden, so sollte das Szenario nicht verlagert werden.
Hebt zum Beispiel vor dem Beenden die Dienstroutine eines Kanals mit höherer Priorität die YBB-Sperre auf (setzt z. B. die Yield-Anzeige 52 in 2 zurück), so tritt in einem Kanal niedrigerer Priorität, dessen YER-Bit gesetzt ist, unverzüglich ein Yield-Ereignis auf. Sammelt eine Dienstroutine eines Kanals mit niedrigerer Priorität Informationen zum Prozessorzustand, so wird eine Information über den Zustand des Prozessors ausgegeben, während er die Dienstroutine höherer Priorität ausführt. Mit anderen Worten, die Dienstroutine des Kanals mit niedrigerer Priorität würde die Dienstroutine des Kanals mit höherer Priorität profilieren, anstelle des Codes, den sie profilieren soll.
Entsprechend kann in verschiedenen Ausführungsformen die Priorität eines Agenten anhand der Art des Dienstbedienprogramms ermittelt werden, welches nach dem Auftreten eines Yield-Ereignisses gemäß einem Szenario durchgeführt wird, das zu einem Agenten gehört. Daher kann die Tatsache, ob eine Dienstroutine vor dem Beenden die YBB-Sperre aufhebt, bei der Bestimmung der Priorität eines bestimmten Software-Agenten helfen. In anderen Ausführungsformen können jedoch verschiedene Arten der Prioritätszuweisung für Agenten (und damit auch der Kanäle) angewendet werden. So kann zum Beispiel die Priorität durch andere Attribute von Dienstbedienprogrammen, Agenten und sogar von der Art des in einen Kanal programmierten Szenarios festgelegt werden.
In manchen Ausführungsformen kann die dynamische Kanalmigration anhand einer Strategie der besten Passform (Best Fit) Szenarios den Kanälen zuweisen. Der nachstehend in Tabelle 3 dargestellte Algorithmus stellt eine Art der DCM-Implementierung dar, obgleich der Rahmen der vorliegenden Erfindung nicht darauf begrenzt ist. In dieser Ausführungsform bestimmt das Verhalten der Dienstroutine bezüglich der Aufhebung der YBB-Sperre während deren Ausführung (vor dem Beenden), welchen Kanal sie benutzen soll.
Tabelle 3
Das vorstehende Beispiel einer Codesequenz progammiert demnach ein von einem Agenten mit niedrigerer Priorität angefordertes Szenario in den Kanal mit der niedrigsten Priorität, der verfügbar ist, und führt dazu bei Bedarf eine dynamische Kanalmigration durch. Falls jedoch andererseits ein Agent, der eine Kanalzuweisung anfordert, eine Dienstroutine ausführen soll, die vor der Rückkehr die YBB-Sperre nicht aufhebt, so wird das zu einem derartigen Agenten gehörige Szenario in den Kanal mit der höchsten Priorität gestellt, bei Bedarf unter Einsatz der dynamischen Kanalmigration.
5 zeigt ein Beispiel für die Kanalzuweisung vor und nach der dynamischen Kanalmigration (DCM) gemäß einer Ausführungsform der vorliegenden Erfindung. 5 illustriert den Fall, in dem ein Client (z.B. ein Software-Agent) anhand des Algorithmus in Tabelle 3 ein Szenario in einen verfügbaren Kanal programmieren will. Wie in 5 dargestellt, wird vor der DCM zu einem Zeitpunkt 80 ein Kanal mit der höchsten Priorität 50a (d. h. Kanal 0) mit einem ersten Szenario 55a progammiert. Insbesondere enthält das Szenario 55a eine zusammengesetzte Bedingung bezüglich eines Cache-Fehltreffers (LFP-LLC Fehltreffer, d. h. Ladefehler-ähnlicher Predata-Ready Last Level Cache (LLC) Fehltreffer). Ein zweiter Kanal 50b (d. h. Kanal 1) mit einer niedrigeren Priorität ist zum Zeitpunkt 80 verfügbar. Die Dienstroutine des zu programmierenden Szenarios hebt die YBB-Sperre nicht auf und folglich wird der das Szenario anfordernde Agent als Agent mit höherer Priorität gewertet als der dem ersten Szenario zugehörige Agent 55a. Da der Kanal mit der höchsten Priorität nicht verfügbar ist, werden die Kanäle mittels DCM migriert, um den Kanal mit der höchsten Priorität freizugeben. Daher wird wie in 5 gezeigt zu einem Zeitpunkt 82 nach der DCM der erste Kanal 50a mit einem neuen Szenario 55b progammiert (LF-LLC Miss-LBR, d. h. Ladefehler-ähnlicher LLC Fehltreffer-Letzter Zweigeintrag), das einem Software-Agenten höherer Priorität zugehörig ist, während das ursprüngliche Szenario 55a nun in dem zweiten Kanal 50B mit niedrigerer Priorität gespeichert wird.
6 illustriert ein weiteres Beispiel der Kanalzuweisung vor und nach der DCM gemäß dem Algorithmus in Tabelle 3. 6 illustriert den Fall, in dem ein Client (z. B ein Software-Agent) ein Szenario in einen verfügbaren Kanal progammieren will. Wie in 6 gezeigt, sind eine Anzahl von Kanälen 50a-50d vorhanden. Vor der DCM zum Zeitpunkt 84 wird ein dritter Kanal 50c (d. h. Kanal 2) mit einem ersten Szenario 55a (dem LF-LLC Fehltreffer LBR Szenario) progammiert, während ein vierter Kanal 50d (d. h. Kanal 3) mit einem zweiten Szenario 55b (IR-LBR, d. h. Instruction Retired Counter Underflow) programmiert ist. Demnach sind die beiden Kanäle mit der höchsten Priorität, nämlich ein erster Kanal 50a (d. h. Kanal 0) und ein zweiter Kanal 50b (d. h. Kanal 1), verfügbar und ein zweites Szenario 55b wird in den Kanal mit der niedrigsten Priorität programmiert, nämlich den vierten Kanal 50d. In der in 6 dargestellten Ausführungsform hebt die Dienstroutine, die im Szenario, das programmiert werden soll, nach einem Yield-Ereignis ausgeführt wird, im Laufe ihrer Ausführung die YBB-Sperre auf. Das erste Szenario 55a und das zweite Szenario 55b heben die YBB-Sperre nicht auf. Da der Kanal mit der niedrigsten Priorität nicht verfügbar ist, werden die Kanäle mittels DCM migriert, um den Kanal mit der niedrigsten Priorität freizugeben.
Gemäß einer Ausführungsform der vorliegenden Erfindung wurde nach einer DCM zu einem Zeitpunkt 86 ein erstes Szenario 55a zu einem zweiten Kanal 50b migriert und ein zweites Szenario 55b zu einem dritten Kanal 50c migriert. Darüber hinaus wurde ein neues drittes Szenario 55c in einem vierten Kanal 50d gespeichert.
Dabei ist zu beachten, dass, wenn ein Szenario in den Kanal mit der niedrigsten Priorität programmiert wird, seine Dienstroutine Daten sammeln kann, die den Zustand des Prozessors reflektieren, wenn er eine in einem Kanal höherer Priorität programmierte Dienstroutine ausführt, falls beide Kanäle gleichzeitig durch die gleiche Anweisung ausgelöst werden und die Dienstroutine des Kanals mit höherer Priorität während der Ausführung die YBB-Sperre aufhebt.
Es wird angenommen, dass die gleiche Anweisung die in einem zweiten Kanal 50b und einem vierten Kanal 50d propagierten Szenarios gleichzeitig auslöst, nachdem die Kanäle migriert wurden. Wenn die LF-LLC-Fehltreffer-LBR-Dienstroutine (ausgeführt aufgrund eines Yield-Ereignisses in einem zweiten Kanal 50b) bei ihrer Ausführung die YBB-Sperre aufhebt, so wird die LFP-LLC-Fehltreffer-Dienstroutine (ausgeführt aufgrund eines Yield-Ereignisses in einem vierten Kanal 50d) unmittelbar nach der in der LF-LLC-Fehlertreffer-LBR-Dienstroutine ausgeführten Aufhebung der Sperre aufgerufen. Versucht die LFP-LLC-Fehltreffer-Dienstroutine den Prozessorzustand zu lesen, so beschreibt der Prozessorzustand, auf den zurückgekehrt wird, den Prozessor im Laufe der Ausführung des LF-LLC-Fehltreffer-LBR-Szenarios, anstelle des vorherrschenden Prozessorzustands bei der Auslösung beider Szenarios. Daher geben die Dienstroutinen in manchen Ausführungsformen für in Kanäle mit niedrigerer Priorität programmierte Szenarios nicht unbedingt einen Prozessorzustand aus, der den beim Auslösen des Szenarios bestehenden Prozessorzustand widerspiegelt. Folglich soll ten in manchen Ausführungsformen Szenarios, die andere Szenarios nicht beeinflussen, in Kanäle mit höherer Priorität programmiert werden, während Szenarios, die andere Szenarios beeinflussen, in den Kanal mit der niedrigsten Priorität programmiert werden, damit diese sich nicht auf andere Szenarios auswirken. Zum Beispiel können Szenarios, die zu Hilfsprozessen gehören, in Kanäle mit niedrigerer Priorität programmiert werden, während mit PGOs verbundene Szenarios in Kanäle höherer Priorität programmiert werden können.
Als weitere Illustration der Kanalzuweisung gemäß dem Algorithmus in Tabelle 3 wird nun angenommen, dass ein Client die Programmierung eines Szenarios in einen verfügbaren Kanal anfordert, wenn zumindest der Kanal mit der niedrigsten Priorität verfügbar ist. In einem derartigen Fall braucht DCM nicht verwendet zu werden, selbst wenn die Dienstroutine die YBB-Sperre nicht aufhebt, weil der Kanal mit der niedrigsten Priorität verfügbar ist. Stattdessen kann das Szenario direkt in den Kanal mit der niedrigsten Priorität programmiert werden.
7 zeigt ein Flussdiagramm eines Verfahrens zur Programmierung der Kanäle gemäß einer Ausführungsform der vorliegenden Erfindung. Wie 7 zeigt, kann das Verfahren 300 mit dem Ausführen eines Programms beginnen, zum Beispiel eines Anwendungsprogramms (Block 310). Im Laufe der Ausführung des Anwendungsprogramms führt der Prozessor verschiedene Schritte aus. Zumindest einige dieser Schritte (und/oder Ereignisse), die im Prozessor stattfinden, können sich auf einen oder mehrere Leistungszähler oder ähnliche Überwachungseinrichtungen im Prozessor auswirken. Wenn also derartige Anweisungen auftreten, die sich auf diese Zähler oder Überwachungseinrichtungen auswirken, können die Leistungszähler gemäß diesen Programmereignissen erhöht werden (Block 320). Danach kann ermittelt werden, ob der aktuelle Prozessorzustand einem oder mehreren Szenarios entspricht (Raute 330). So kann zum Beispiel der Wert für einen Leistungszähler, der Cache-Fehltreffer erfasst, mit einem bestimmten Wert verglichen werden, der in ein oder mehrere Szenarios in verschiedenen Kanälen programmiert ist. Entspricht der Prozessorzustand keinem Szenario, so kehrt die Steuerung wieder zum Block 310 zurück.
Wird stattdessen bei Raute 330 ermittelt, dass der Prozessorzustand einem oder mehreren Szenarios entspricht, so kann die Steuerung mit Block 340 fortfahren. Dort kann eine Yield-Ereignisanforderungsanzeige (YER-Anzeige) für den Kanal oder die Kanäle mit dem/den passenden Szenario/Szenarios gesetzt werden (Block 340). Diese YER-Anzeige kann somit anzeigen, dass das in den Kanal programmierte zugehörige Szenario seine zusammengesetzte Bedingung erfüllt hat.
Folglich kann der Prozessor ein Yield-Ereignis für den Kanal mit der höchsten Priorität erzeugen, dessen YER-Anzeige gesetzt ist (Block 350). Dieses Yield-Ereignis überträgt die Steuerung an eine Dienstroutine, nämlich einer Routine, deren Adresse in den ausgewählten Kanal programmiert wird. Folglich kann danach die Dienstroutine ausgeführt werden (Block 360). Nach der Ausführung der Routine kann ermittelt werden, ob zusätzliche YER-Anzeigen gesetzt sind (Raute 370). Ist dies nicht der Fall, so kann die Steuerung wie vorstehend erörtert zum Block 310 zurückkehren. Sind stattdessen zusätzliche YER-Anzeigen gesetzt, so kann die Steuerung von Raute 370 wie vorstehend erörtert zum Block 350 zurückkehren.
Vor dem Aufrufen einer Dienstroutine z. B. während eines Yields, kann der Prozessor jedoch verschiedene Werte in einen Benutzerstapel stellen, wo zumindest einige der Werte für die Dienstroutine(n) zugänglich sind. Insbesondere kann der Prozessor in manchen Ausführungsformen den aktuellen Befehlszähler (Current Instruction Pointer = EIP) in diesen Stapel stellen. Der Prozessor kann außerdem Steuerungs- und Statusinformationen wie eine modifizierte Version eines Bedingungscodes oder Bedingungsattribut-Register (z. B. ein EFLAGS-Register in einer xS6-Umgebung) in den Stapel stellen. Des Weiteren kann der Prozessor die Kanalkennung des den Yield liefernden Kanals in den Stapel stellen.
In manchen Ausführungsformen kann eine Dienstroutine zum Bearbeiten des einen oder der mehreren Kanäle ausgeführt werden, gemäß den folgenden Funktionen einer höheren Ebene: Ermittlung des Yield-Kanals, Bearbeiten des Vorkommnisses, Umprogrammierung des Kanals (bei Bedarf) und Beenden. Um zu ermitteln, welcher Kanal das Yield liefert, kann das Bedienprogramm den letzten Wert (d. h. die Kanalkennung) aus dem Stapel nehmen. Dieser Wert gibt Aufschluss über den Kanal, der das Yield geliefert hat, und kann als Kanalkennung in verschiedenen Schritten oder Anweisungen während einer Dienstroutine verwendet werden.
Wenn ein Kanal ein Yield liefert, so wird seine zugehörige Dienstroutine aufgerufen und kann das Vorkommnis entsprechend bearbeiten. Abhängig vom Nutzungsmodell kann die Dienstroutine Code ausführen, um den aktuellen Prozessorzustand (wie durch die Definition im Szenario definiert) zu nutzen, Daten zu sammeln oder den Kanalzustand zu lesen. Anlässlich des Yields kann die Dienstroutine außerdem den Kanal entsprechend der Definition im Szenario umprogammieren. So können zum Beispiel Zählszenarios während einer Dienstroutine umprogrammiert werden.
Zum Beenden einer Dienstroutine können verschiedene Schritte erfolgen. Zum Beispiel kann das modifizierte EFLAGS-Bild, das während der Yield-Erfassung in den Stapel gestellt wurde, zurück in das EFLAGS-Register gestellt werden. Danach kann das modifizierte EIP-Bild, das während der Yield-Erfassung in den Stapel gestellt wurde, zurück in das EIP-Register gestellt werden. Auf diese Weise kann der ursprünglich ausgeführte Software-Thread die Ausführung wieder aufnehmen. Dabei ist zu beachten, dass die zu Yield-Beginn in den Stapel gestellte Kanalkennung nicht aus dem Stapel entnommen werden muss. Wie vorstehend erörtert kann dieser Stapelwert stattdessen während der Dienstroutine entnommen werden.
Implementierungen können in Verbindung mit Architekturen zum Beispiel zur Nutzung in verwalteten Laufzeitanwendungen und Serveranwendungen verwendet werden. Ausführungsformen der vorliegenden Erfindung können zur Einrichtung und Steuerung von Prioritäten unter zu bearbeitenden Ereignissen verwendet werden, die von einer oder mehreren Anweisungen in mehreren Kanälen ausgelöst werden. Auf diese Weise können Ereignisse gemäß der Kanalpriorität behandelt werden, was gleichzeitig die Durchführbarkeit der Hardware-Implementierung sowie die Erfüllung der Softwarefunktionalität ermöglicht.
8 zeigt ein Blockdiagamm eines Multiprozessorsystems gemäß einer Ausführungsform der vorliegenden Erfindung. Wie 8 zeigt, ist das Multiprozessorsystem ein System mit Punkt-zu-Punkt-Verbindung und umfasst einen ersten Prozessor 470 sowie einen zweiten Prozessor 480, die über eine Punkt-zu-Punkt-Verbindung 450 gekoppelt sind. Wie 8 zeigt, kann jeder der Prozessoren 470 und 480 mehrkernig sein und einen ersten und zweiten Prozessorkern umfassen (d. h. Prozessorkerne 474a und 474b sowie Prozessorkerne 484a und 484b). Obgleich aus Illustrationszwecken nicht gezeigt, können ein erster Prozessor 470 und ein zweiter Prozessor 480 (und insbesondere deren Kerne) gemäß einer Ausführungsform der vorliegenden Erfindung mehrere Kanäle umfassen. Des Weiteren umfasst ein erster Prozessor 470 einen Speichersteuerungs-Hub (Memory Controller Hub = MCH) 472 sowie Punkt-zu-Punkt- (P-P) Schnittstellen 476 und 478. Entsprechend umfasst ein zweiter Prozes sor 480 einen MCH 482 und P-P-Schnittstellen 486 und 488. Wie in 8 gezeigt, koppeln Speichersteuerungs-Hubs 472 und 482 die Prozessoren an respektive Speicher, nämlich einen Speicher 432 und einen Speicher 434, die wiederum einen Teil des dem jeweiligen Prozessor lokal zugeordneten Hauptspeichers darstellen können.
Ein erster Prozessor 470 und ein zweiter Prozessor 480 können über die jeweiligen P-P-Schnittstellen 452 und 454 an einen Chipsatz 490 gekoppelt sein. Wie in 8 gezeigt, umfasst der Chipsatz 490 die P-P-Schnittstellen 494 und 498. Des Weiteren umfasst der Chipsatz 490 eine Schnittstelle 492 zur Kopplung des Chipsatzes 490 mit einer Hochleistungsgrafikmaschine 438. In einer Ausführungsform kann ein Advanced Graphics Port (AGP) Bus 439 zur Kopplung der Grafikmaschine 438 an den Chipsatz 490 eingesetzt werden. Der AGP-Bus 439 kann der von der Intel Corporation, Santa Clara, Kalifornien am 4. Mai 1998 veröffentlichten Accelerated Graphics Port Interface Specification, Revision 2. entsprechen. Alternativ dazu können diese Komponenten über eine Punkt-zu-Punkt-Verbindung 439 gekoppelt werden.
Der Chipsatz 490 kann wiederum über eine Schnittstelle 496 an einen ersten Bus 416 gekoppelt sein. In einer Ausführungsform kann ein erster Bus 416 ein PCI-Bus (Peripheral Component Interconnect = PCI) gemäß der PCI Local Bus Specification, Production Version, Revision 2.1 datiert Juni 1995 oder PCI Express Bus oder ein anderer I/O-Bus der dritten Generation sein, obgleich der Rahmen der vorliegenden Erfindung nicht darauf beschränkt ist.
Wie in 8 gezeigt, können verschiedene Eingabe-/Ausgabevorrichtungen (I/O-Vorrichtungen) 414 an einen ersten Bus 416 gekoppelt sein, zusammen mit einer Busbrücke 418, über die ein erster Bus an einen zweiten Bus 420 gekoppelt ist. In einer Ausführungsform kann ein zweiter Bus 420 ein LPC-Bus (LPC = Low Pin Count) sein. In einer Ausführungsform können verschiedene Geräte an einen zweiten Bus 420 gekoppelt sein, wie zum Beispiel eine Tastatur/Maus 422, Kommunikationsgeräte 426 und eine Datenspeichereinheit 428, die Code 430 enthalten kann. Darüber hinaus kann ein Audio-Eingang/Ausgang 424 an den zweiten Bus 420 gekoppelt sein.
Ausführungsformen können in Code implementiert werden und auf einem Speichermedium gespeichert werden, auf dem Anweisungen dafür gespeichert sind, die zur Programmierung eines Systems und zur Ausführung der Anweisungen genutzt werden können. Dazu können zum Beispiel, jedoch nicht ausschließlich, Speichermedien folgender Art verwendet werden: Jegliche Art von Datenträger, einschließlich Disketten, optische Speicherplatten, nur lesbare optische Speicherplatten (CD-ROM), wieder beschreibbare optische Speicherplatten (CD-RW), magneto-optische Platten, Halbleitervorrichtungen wie nur lesbare Speicher (ROM), Direktzugriffsspeicher (RAM) wie dynamische Direktzugriffsspeicher (DRAM), statische Direktzugriffsspeicher (SRAM), löschbare programmierbare Festwertspeicher (EPROM), Flash-Speicher, elektrisch löschbare programmierbare Festwertspeicher (EEPROM), magnetische oder optische Karten, oder beliebige sonstige zur Speicherung elektronischer Anweisungen geeignete Medien.
Obgleich die vorliegende Erfindung anhand einer begrenzten Anzahl an Ausführungsformen beschrieben worden ist, ist Fachleuten offensichtlich, dass sie in zahlreichen Modifikationen und Variationen existieren kann. Die Ansprüche im Anhang sollen sämtliche derartige Modifikationen und Variationen abdecken, die unter den echten Geist und Rahmen der vorliegenden Erfindung fallen.

Claims

Verfahren, das Folgendes umfasst: Bestimmen einer relativen Priorität zwischen einem ersten und einem zweiten Agenten und Zuweisen des ersten Agenten zu einem ersten Kanal und des zweiten Agenten zu einem zweiten Kanal gemäß der relativen Priorität.
Verfahren nach Anspruch 1, bei dem das Zuweisen des ersten Agenten und des zweiten Agenten eine dynamische Migration eines ersten Szenarios, das zu dem zweiten Agenten gehört, vom ersten Kanal zum zweiten Kanal anhand der relativen Priorität umfasst.
Verfahren nach Anspruch 2, das außerdem ein Speichern eines zweiten Szenarios, das zum ersten Agenten im ersten Kanal gehört, umfasst, wobei der erste Kanal eine höhere Priorität hat als der zweite Kanal.
Verfahren nach Anspruch 3, bei dem das Speichern des zweiten Szenarios ein Speichern einer Adresse für eine Dienstroutine umfasst, die zum zweiten Szenario im ersten Kanal gehört.
Verfahren nach Anspruch 2, das weiterhin ein Speichern einer Kanalkennung, die dem zweiten Kanal entspricht, in einem Stapel beim Auftreten eines Yield-Ereignisses des ersten Szenarios umfasst.
Verfahren nach Anspruch 5, das weiterhin ein Abrufen der Kanalkennung aus dem Stapel durch eine Bedienprogramm für das erste Szenario umfasst.
Verfahren nach Anspruch 1, das weiterhin eine Verwaltung der ersten Kanals und des zweiten Kanals anhand der relativen Priorität zwischen dem und dem zweiten Kanal umfasst.
Verfahren nach Anspruch 1, das weiterhin Folgendes umfasst: Speichern eines ersten Szenarios, das zum ersten Agenten im ersten Kanal gehört, und Speichern eines zweiten Szenarios, das zum zweiten Agenten im zweiten Kanal gehört, sowie Behandeln des ersten Szenarios und des zweiten Szenarios, ausgelöst über eine einzige Anweisung gemäß der relativen Priorität des ersten Kanals und des zweiten Kanals.
Verfahren nach Anspruch 1, das weiterhin Folgendes umfasst: Ausführen einer Anweisung, die ein im ersten Kanal gespeichertes erstes Szenario und ein im zweiten Kanal gespeichertes zweites Szenario auslöst, und Bearbeiten des ersten Szenarios und des zweiten Szenarios.
Verfahren nach Anspruch 9, das weiterhin Folgendes umfasst: Bearbeiten desjenigen des ersten Szenarios und des zweiten Szenarios, das zu demjenigen des ersten Kanals und des zweiten Kanals gehört, der die höhere relative Priorität besitzt.
Vorrichtung, die Folgendes umfasst: einen ersten Kanal zum Speichern einer ersten zusammengesetzten Bedingung, wobei der erste Kanal eine erste Kanalpriorität besitzt; einen zweiten Kanal zum Speichern einer zweiten zusammengesetzten Bedingung, wobei der zweite Kanal eine zweite Kanalpriorität besitzt; einen Kontroller zum Auswählen von einem des ersten Kanals und des zweiten Kanals zum Verknüpfen mit einem Software-Agenten anhand einer Zuordnung einer Priorität des Software-Agenten zur ersten Kanalkpriorität oder zur zweiten Kanalpriorität.
Vorrichtung nach Anspruch 11, bei welcher der Kontroller eine Ressourcenverwaltung zum Auswählen von einem des ersten Kanals und des zweiten Kanals umfasst aufgrund eines ersten Bedienprogramms und eines zweiten Bedienprogramms, die beim Auftreten der ersten bzw. der zweiten zusammengesetzten Bedingung ausgeführt werden.
Vorrichtung nach Anspruch 12, bei der das erste Bedienprogamm eine Optimierungsroutine und das zweite Bedienprogramm eine Hilfsroutine umfasst.
Vorrichtung nach Anspruch 11, die weiterhin ein erstes Bedienprogramm umfasst, das an einer im ersten Kanal gespeicherten Adresse befindet, wobei das erste Bedienungsprogramm Anweisungen umfasst, die ausgeführt werden, wenn ein Yield-Ereignis auftritt, das die erste zusammengesetzte Bedingung erfüllt.
Vorrichtung nach Anspruch 14, bei der das erste Bedienprogramm dazu dient, eine Kanalkennung von einem Speicher abzurufen, die dem ersten gespeicherten Kanal entspricht.
Vorrichtung nach Anspruch 11, wobei die Vorrichtung einen Prozessor mit mehreren von Kanälen umfasst.
Vorrichtung nach Anspruch 16, bei welcher der Prozessor einen ersten Kern und einen zweiten Kern umfasst, wobei der erste und der zweite Kern jeweils mindestens zwei Kanäle umfassen.
Vorrichtung nach Anspruch 11, die weiterhin eine dem ersten Kanal und dem zweiten Kanal zugehörige Yield-Sperre umfasst, um das Auftreten der ersten zusammengesetzten Bedingung und der zweiten zusammengesetzten Bedingung während der Ausführung einer Dienstroutine zu verhindern, die zum ersten oder zum zweiten Kanal gehört.
Vorrichtung nach Anspruch 11, bei welcher der erste Kanal Folgendes umfasst: einen Speicher zum Speichern der ersten zusammengesetzten Bedingung, eine Adresse für das Bedienprogramm, das beim Auftreten der ersten zusammengesetzten Bedingung ausgeführt wird, eine Yield-Anzeige zum Anzeigen des Vorkommnisses und eine Programmanzeige zum Anzeigen des Vorhandenseins von Informationen im ersten Kanal.
Gegenstand, der ein maschinell lesbares Speichermedium mit Anweisungen umfaßt, die, wenn sie von einer Maschine ausgeführt werden, die Maschine in die Lage versetzen, ein Verfahren durchzuführen, welches Folgendes umfasst: Zuweisen eines ersten Software-Agenten zu einem ersten Kanal; Zuweisen eines zweiten Software-Agenten zu einem zweiten Kanal, wobei die Zuweisung dazu dient, eine relative Priorität des ersten und des zweiten Software-Agenten zu einer relativen Priorität des ersten und des zweiten Kanals anzupassen, und Programmieren des ersten Kanals mit einem ersten Szenario und Programmieren des zweiten Kanals mit einem zweiten Szenario, wobei die relative Priorität des ersten und des zweiten Software-Agenten auf Typen von Bedienprogrammen für das erste und das zweite Szenario basiert.
Gegenstand nach Anspruch 20, bei dem das Verfahren weiterhin eine dynamische Migration eines im ersten Kanal gespeicherten Szenarios zu einem anderen Kanal umfasst.
Gegenstand nach Anspruch 21, bei dem das Verfahren weiterhin eine dynamische Migration eines Szenarios umfasst, basierend auf einer relativen Priorität zwischen einem vorherigen dem ersten Kanal zugewiesenen Agenten und einem neuen Agenten.
System, das Folgendes umfasst: einen Prozessor umfassend: eine oder mehrere Ausführungsressourcen, einen ersten Kanal mit einem ersten Speicher zum Speichern erster Informationen, die zu einer ersten Gruppe von Überwachungseinrichtungen gehört, einschließlich mindestens einer Überwachungseinrichtung, wobei die erste Information gemäß einer Anforderung eines ersten Agenten zu speichern ist, einen zweiten Kanal mit einem zweiten Speicher und einen Kontroller zur dynamischen Migration der ersten Information aus dem ersten Kanal zum zweiten Kanal, wenn ein neuer Agent die Zuweisung eines Kanals anfordert, und einen an den Prozessor gekoppelter dynamischer Direktzugriffsspeicher (DRAM).
System nach Anspruch 23, bei dem der DRAM einen Benutzerstapel umfasst, um die zum ersten Kanal gehörige Information nach dem Auftreten der ersten zusammengesetzten Bedingung zu speichern.
System nach Anspruch 24, bei dem die Information des ersten Kanals eine Kanalkennung umfasst zur Verwendung durch ein Dienstbedienungsprogramm, das nach dem Auftreten der ersten zusammengesetzten Bedingung ausgeführt wird.
System nach Anspruch 23, bei dem der Prozessor einen Multiprozessor umfasst, der mehrere Kerne enthält, wobei jeder dieser Kerne jeweils mehrere Kanäle enthält.
System nach Anspruch 23, bei dem die erste Information Folgendes enthält: eine erste zusammengesetzte Bedingung, eine Adresse für ein Bedienprogramm, das nach dem Auftreten der ersten zusammengesetzte Bedingung ausgeführt wird, sowie eine Yield-Anzeige zur Anzeige des Vorkommnisses.
System nach Anspruch 23, bei dem der Kontroller die erste Information anhand einer relativen Priorität des neuen Agenten und des ersten Agenten dynamisch migriert.
System nach Anspruch 28, wobei der erste Kanal eine höhere Priorität hat als der zweite Kanal und der neue Agent eine höhere relative Priorität hat als der erste Agent.