-
GEBIET
-
Ausgestaltungen der Erfindung betreffen einen Multithreadprozessor und insbesondere das Verarbeiten von Threads in Multithreadprozessoren.
-
HINTERGRUND
-
Ein Anwendungsprogramm kann in Threads aufgeteilt werden, die Abfolgen von Anweisungen, wie etwa ausführbare Einheiten, sind, die auf der Zentralverarbeitungseinheit (Central Processing Unit; CPU) eines Computers ausgeführt werden. Allgemein wird ein Programm zunächst in Softwarethreads durch das Betriebssystem unterteilt, dann wird jeder Softwarethread gemapped oder in einen korrespondierenden Hardwarethread in einer CPU eingereiht, die üblicherweise eine Menge von Registern in einer CPU sind. Um die Threads mit einer schnelleren Geschwindigkeit zu verarbeiten, können Multithreadprozessoren verwendet werden, die gleichzeitig mehrere Threads zu einer bestimmten Zeit empfangen und verarbeiten können.
-
Während der Softwarethreaderzeugung werden einige Threads eine mit diesen assoziierte höhere Priorität als andere zu haben angesehen. Das Betriebssystem priorisiert daher Softwarethreads basierend auf gewünschten Leistungseigenschaften. Ein Verfahren der Threadpriorisierung durch das Betriebssystem ist die Time-Slice Methode (Zeitintervallverfahren), das heute von Multiprozessorsystemen verwendet wird. Bei diesem Verfahren empfängt ein Softwarethread mit höherer Priorität häufiger Zeitintervalle als einer mit einer geringeren Priorität und wird vom Multiprozessorsystem mehr umsorgt, wodurch sich oftmals eine bessere Leistung ergibt.
-
Während der Verwendung mit Multiprozessorsystemen, ist die vorstehende Priorisierungsmethode in Multithreadumgebungen uneffektiv, bei denen Ressourcen gleichzeitig ausführenden Threads gleichmäßig beansprucht werden. Das Problem tritt auf, wenn die priorisierten Softwarethreads in Hardwarethreads zum Ausführen eines Multithreadprozessor gemapped werden. Derzeit behandeln Multithreadprozessoren jeden Hardwarethread gleich, ungeachtet deren zugeordneter Softwarelevelpriorität, wodurch die Effektivität der anfänglichen Betriebssystempriorisierung der Threads reduziert wird.
-
Ein Grund für diesen Mangel im Stand der Technik liegt am Cachesystem des Multithreadprozessors. Üblicherweise wurden Cacheerneuerungsalgorithmen, die für das Betreiben des Cachesystems verwendet werden, eingerichtet, um symmetrische Behandlung aller Threads bereitzustellen. In symmetrischen Multiprozessorsystemen jedoch beeinträchtigt die gleichzeitige Ausführung von verschiedenen Aufgaben von Hardwarethreads (i. e. ohne Priorisierung) die Leistung, speziell von Echtzeitthreads, denen oftmals von der Software höhere Priorität gegeben wird. Dieses kann ein Hindernis für Workstations und Kleinbüros sein, wenn viele Routinewartungsarbeiten, wie etwa Pestplattenfragmentierung und Virusscans, gleichzeitig mit Echtzeitaufgaben, wie etwa Multimediadecodierung ablaufen.
-
Aus dem Dokument
US 5,787,490 A ist ein Multiprozessorsystem mit einen Cache, einer Cachezuweisungseinheit und einer Cachesteuereinheit bekannt, wobei die Cachezuweisungseinheit Prozessen eine Cachenutzungspriorität zuweist und die Cachesteuereinheit einen Zugriff der Prozesse auf den Cache entsprechend der zugewiesenen Priorität steuert. Hierbei kann die Cachenutzungspriorität auf statistischen Informationen bezüglich einer Hit/Missrate basieren.
-
Das Dokument
US 6,604,174 B1 beschreibt, wie in einem Multiprozessorsystem Prozessen, welche eine hohe Missrate aufweisen, mehr Cachespeicher zugeteilt werden als Prozessen, welche eine niedrige Missrate aufweisen, wobei hier auch noch weitere Systemvariablen, beispielsweise die Gesamtleistung des Systems, bei der Cachezuordnung berücksichtigt werden können.
-
Die Aufgabe der vorliegenden Erfindung besteht somit darin, ein System zur Leistungspriorisierung von Multithread-Prozessoren bereitzustellen, das eine über eine Priorisierung von Software-Threads hinausgehende priorisierte Behandlung von Threads ermöglicht.
-
Die Aufgabe wird gelöst durch ein System mit den Merkmalen gemäß Anspruch 1 sowie ein Verfahren mit den Merkmalen gemäß Anspruch 7.
-
Vorteilhafte Ausführungsformen sind in den Unteransprüchen angegeben.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1 stellt eine Multithreadprozessorumgebung dar, in der beispielhafte Ausgestaltungen der Erfindung ausgeführt sein können.
-
2A–B stellt beispielhafte Ausgestaltung der Erfindung dar.
-
3 ist ein Flussdiagramm, das ein Verfahren gemäß einer beispielhaften Ausgestaltung der Erfindung darstellt.
-
4 ist ein Flussdiagramm, das weiter das in 3 beispielhaft dargestellte Verfahren darstellt.
-
5 ist ein Kreisdiagramm der beispielhaften Ausgestaltungen der Erfindung, die in 2A–B gezeigt sind.
-
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
-
Ausführungsbeispiele der Erfindung betreffen allgemein ein System und ein Verfahren zur Leistungspriorisierung in Multithreadprozessoren. Hier sind Ausgestaltungen der Erfindung bei Multithreadprozessoren anwendbar, die in einer Vielzahl von Computervorrichtungen verwendet werden, die allgemein als stationäre oder mobile elektronische Vorrichtungen betrachtet werden. Beispiele von Computervorrichtungen schließen ein, sind aber nicht darauf begrenzt oder beschränkt: Computer, Workstations. Beispielsweise kann die Computervorrichtung allgemein als jede Art von stationärer oder mobiler elektronischer Vorrichtung angesehen werden, wie etwa einer Set-Top Box, drahtlosem Telefon, digitaler Videorecorder (DVR), Netzwerkgeräte (z. B. Router, Server, etc.) und ähnliches.
-
Bestimmte Details werden im Folgenden beschrieben, um ein vollständiges Verständnis der verschiedenen Ausgestaltungen der Erfindung zu ermöglichen, obgleich Ausgestaltungen der Erfindung mittels vieler anderer Ausführungsbeispiele als die dargestellten, ausgeführt werden können. Gut bekannte Logik und Abläufe werden nicht im Detail beschrieben, um unnötiges Verschleiern der Beschreibung zu vermeiden.
-
In der folgenden Beschreibung wird bestimmte Terminologie verwendet, um Merkmale der verschiedenen Ausgestaltungen der Erfindung zu beschreiben. Beispielsweise schließt der Begriff „Multithreadprozessor” jede Vorrichtung ein, die zwei oder mehr Datenthreads gleichzeitig verarbeitet. Der Ausdruck „Softwarethread” betrifft Abfolgen von Anweisungen, wie etwa ausführbaren Einheiten, die aus dem Aufteilen in derartige Anweisungsabfolgen durch ein Softwareprogramm resultieren und die dann auf einem Prozessor ausgeführt werden können, wie etwa einer Zentralverarbeitungseinheit (Central Processing Unit; CPU) einer Computervorrichtung. Der Ausdruck „Hardwarethread betrifft eine Menge von Registern oder andere Speichermedien in einem Prozessor, in den die Softwarethreads gemapped oder eingereiht werden.
-
Der Ausdruck „Software” bezeichnet allgemein ausführbaren Code, wie etwa ein Betriebssystem, eine Anwendung, ein Applet, eine Routine oder eine oder mehrere Anweisungen. Die Software kann in jeder Art von Speicher, nämlich einem geeigneten Speichermedium wie etwa einem programmierbaren elektronischen Schaltkreis, einer Halbleiterspeichervorrichtung, einem flüchtigen Speicher (z. B. Random Access Memory etc.), einem nicht-flüchtigen Speicher (z. B. Read-Only Memory, Flash Speicher, etc.), einer Floppydiskette, einer optischen Scheibe (z. B. Compact Disk oder Digital Versatile Disc „DVD”), einer Festplatte, Band oder jeder Art von Verbindung (wie unten definiert) gespeichert werden.
-
Mit Bezug auf 1 ist eine Multithreadprozessorumgebung 1 dargestellt, wie etwa diejenige eines Computers oder einer Workstation, in der beispielhafte Ausgestaltungen der Erfindung ausgeführt sein können. Wie in 1 gezeigt, weist die Multithreadprozessorumgebung 1 Software 101 und damit verbundene Hardware 102 auf. Die Software 101 weist ein oder mehrere Anwendungsprogramme 103 und ein Betriebssystem 104 auf. Die Hardware 102 weist ein Multithreadprozessorteilsystem 107 mit einem Cacheteil 105 auf, das in Kommunikation mit einem Prozessor 106, wie etwa einem Prozessorkern, ist. Wie oben beschrieben, unterteilt das Betriebssystem während der Ausführung des Anwendungsprogramms 103 die vom Anwendungsprogramm 103 auszuführenden Aufgaben in Softwarethreads 10, wie etwa ST_1 bis ST_N (N > 1), die Abfolgen von Anweisungen, wie etwa ausführbaren Einheiten, sind. Wie in 1 gezeigt, wird jeder Softwarethread 10 dann gemapped oder in einem korrespondierenden Hardwarethread 103 eingereiht, wie etwa HT_1 bis HT_N (N > 1), die üblicherweise Mengen von Registern sind, und dann verarbeitet, wie etwa gleichzeitig, von dem Prozessor 106. Wie in 1 gezeigt, ist die Interaktion zwischen dem Prozessor 106 und dem Cacheteilsystem 105 in Bezug auf das Verarbeiten der Hardwarethreads 11 vom Hardwarethreadzuordnungsteilsystem 200 und dem Cachenutzungsüberwachungsteilsystem 210 gesteuert, wie in größerem Detail in Zusammenhang mit den 2A–B im Folgenden beschrieben.
-
Die 2A–B zeigen beispielhafte Ausgestaltungen der Erfindung. Zur einfacheren Darstellung ist der Prozessor 106 ein Dual-Threadprozessor, obwohl andere Prozessoren, die fähig sind, jede Anzahl von Threads zu verarbeiten, auch als innerhalb des Umfangs der beispielhaften Ausgestaltungen der Erfindung angesehen werden. Wie in 2A gezeigt, ist das Cacheteilsystem 105 in Kommunikation mit dem Prozessor 106, etwa über das Signal 203 zum Lesen und Schreiben von Daten vom und in das Cacheteilsystem 105 und über die Signale 205, 206 und 201 zum Verarbeiten der Hardwarethreads 11. Das Cacheteilsystem 105 weist weiter eine Datenanordnung 250 einschließlich einer Mehrzahl von Cachewegen 251, wie etwa way_0 bis way_n (n > 1), zum Speichern von Daten von den Hardwarethreads 11 auf. Das Multithreadprozessorteilsystem 107 weist weiter ein Hardwarethreadzuordnungsteilsystem 200 auf, das ein Cachewegauswahllogikteilsystem (CSL) 202 benutzt, zum Auswählen einer Teilmenge von Cachewegen 250 zum Speichern von Daten von den Hardwarethreads 11, die als Hardwarethreads hoher Priorität 11 zum Verarbeiten durch den Prozessor 106 identifiziert wurden, wie in größerem Detail im Zusammenhang mit 5 beschrieben wird. Basierend auf der Auswahl des Cachewegauswahllogikteilsystems 202 ordnet das Hardwarethreadzuordnungsteilsystem 200 Hardwarethreads hoher Priorität 11 der Teilmenge von Cachewegen 251 zu, die zum Speichern von Hardwarethreads hoher Priorität 11 ausgewählt wurden.
-
Wie weiter in 2 gezeigt, weist das Multithreadprozessorteilsystem 107 weiter ein Cachenutzungsüberwachungsteilsystem 210 auf, das in Kommunikation mit dem Cacheteilsystem 105 ist und zum Überwachen eines Hardwarethreads hoher Priorität 11, wie etwa HT_1, der der Teilmenge von Cachewegen 251 zugeordnet ist, die zum Speichern von Hardwarethreads hoher Priorität 11 ausgewählt sind und zum Vergleichen der überwachten Nutzung des Hardwarethreads hoher Priorität HT_1 mit einem vorbestimmten Cachenutzungsschwellenwert, wie in größerem Detail in Zusammenhang mit 3–5 im Folgenden beschrieben wird. Das Hardwarethreadzuordnungsteilsystem 200 kann den zugeordneten Hardwarethread hoher Priorität HT_1 einem der Cachewege 251 erneut zuordnen, wenn die Cachenutzung des Hardwarethreads hoher Priorität HT_1 den vorbestimmten Cachenutzungsinaktivitätsschwellenwert überschreitet. Nach dieser erneuten Zuordnung ignoriert das Hardwarethreadzuordnungsteilsystem 200 die Auswahl der Teilmenge von Cachewegen 251 zum Speichern von Daten der Hardwarethreads hoher Priorität 11 und kann den Hardwarethread HT_1 an irgendeines der Cachewege 251 in der Datenanordnung 250 erneut zuordnen. Würde der Hardwarethread HT_1 die aktive Cachenutzung auf die erneute Zuordnung folgend wieder aufnehmen, würde die erneute Zuordnung aufgehoben und die oben genannte threadbasierte Auswahl würde automatisch reaktiviert werden.
-
3 ist ein Flussdiagramm, das in Zusammenhang mit 2A–B ein Verfahren gemäß einer beispielhaften Ausgestaltung der Erfindung darstellt. Wie in 3 gezeigt, beginnt das Verfahren bei Block 300 und schreitet zum Entscheidungsblock 310 fort, in dem bestimmt wird, ob wenigstens einen Cacheweg einen Hardwarethread 11 nicht aufnimmt (z. B. hat es keine hier gespeicherten relevanten Daten). Wie in 2A gezeigt, weist das Cacheteilsystem 105 eine Statusanordnung 270 auf, die eine Menge von Werten 271, wie etwa value_0 bis value_n (n > 1) aufrechterhält, mit jedem Wert 271, der einen Cacheweg 251 in der Datenanordnung 250 entspricht. Jeder Wert 271, wie etwa value_0, zeigt an, ob ein korrespondierender Cacheweg 251, wie etwa way_0 einen Hardwarethread 11 aufnimmt. Geeigneterweise weist ein Wert 271 einen binären Wert mit einem Wert, wie etwa 1, auf, der anzeigt, dass ein korrespondierender Cacheweg 251 „gültig” ist (z. B., nimmt er einen Hardwarethread 11 auf) und ein anderer Wert, wie etwa Null, zeigt an, dass der Cacheweg 251 „ungültig” ist (z. B., nimmt er keinen Hardwarethread 11 auf).
-
Wird in Block 310 bestimmt, dass alle der Cachewege 251 einen Hardwarethread 11 aufnehmen, dann schreitet der Ablauf zu Block 320 fort, in dem eine Teilmenge von Cachewegen 251 zum Speichern von Hardwarethreads 11 ausgewählt wird, die als Hardwarethreads hoher Priorität 11 (wie etwa durch das Betriebssystem 104) zum Verarbeiten durch den Prozessor 106 identifiziert wurden.
-
Wie in 2A gezeigt, weist das Cacheteilsystem 105 eine Ersatzregelungsanordnung (Replacement Policy Array; RPA) 240 auf, die bestimmt, welchem Cacheweg 251 ein bestimmter Hardwarethread 11 zugeordnet werden kann. In einer beispielhaften Ausgestaltung der Erfindung wird eine Threadmaske hoher Priorität 230 verwendet, um die Auswahl der RPA 240 zu verändern, so dass eine Teilmenge der Cachewege 251 zurückgestellt wird, um für nur Hardwarethreads hoher Priorität 11 verwendet zu werden. Geeigneterweise ist die Anzahl von Cachewegen 251, die zurückgestellt wurden, um für Hardwarethreads nur hoher Priorität 11 verwendet zu werden, größer als die Hälfte der Gesamtanzahl von Cachewegen 251 in einer Statusanordnung 250. Geeigneterweise ist die Threadmaske 230 hoher Priorität eine Abfolge von Bits, die ein Signal 232 erzeugen, das wenn auf die Bits des Entscheidungssignals 241 der RPA 240 angewendet, die RPA 240 veranlasst, nur auf eine Teilmenge der Cachewege 251 zu verweisen. Geeigneterweise weist die Threadmaske hoher Priorität 230 ein oder mehrere Register (nicht gezeigt) zum Speichern der Maskierungsbits hoher Priorität auf.
-
2B stellt ein Beispiel dieser Anwendung einer Threadmaske hoher Priorität 230 für ein Entscheidungssignal 241 der RPA 240. Zur einfachen Darstellung wird ein Pseudo-LRU Algorithmus (PLRU) von RPA 240 für einen Achtwegecache (way_0 bis way_7) verwendet, und auf den eine 7-Bit (B0 bis B7) Threadmaske hoher Priorität 230 angewendet wird. In diesem Beispiel werden jedes Mal, wenn die Threadmaske hoher Priorität 230 aktiviert ist und es eine Anfrage 206 (gezeigt in 2A) zum Füllen eines Cacheweges 250 durch einen Hardwarethread hoher Priorität 11 gibt, die Bits der Threadmaske hoher Priorität 230 auf die PLRU Bits angewendet, wie symbolisch durch den Entscheidungsbaum 2 dargestellt gezeigt. Das Anwenden einer vorbestimmten Threadmaske hoher Priorität 230 (basierend auf den im Stand der Technik gut bekannten Grundlagen) resultiert in einer Beeinflussung von bit1 der PLRU (gezeigt in Baum 2) auf 0 und welches letztendlich im Verfügbarmachen von ways_2 bis way_7 für Hardwarethreads nur hoher Priorität 11 resultiert. Daher wird durch Vorbestimmen der Bits der Threadmaske hoher Priorität 230 basierend auf den PLRU Bits zum Hervorbringen der oben genannten Ergebnisse eine Teilmenge 280 der Cachewege, die way_2 bis way_7 aufweist, zurückgestellt, um für Hardwarethreads nur hoher Priorität 11 verwendet zu werden. Der Vorgang an Block 320 in 3 erzeugt daher eine Anpassung in den Entscheidungen der RPA 240 zugunsten der Threads hoher Priorität 11, wodurch die Verfügbarkeit der Ressourcen des Cacheteilsystems 105 für die Hardwarethreads hoher Priorität 11 verbessert wird.
-
Eine Threadmaske geringer Priorität 220 kann ähnlich auf Threads geringer Priorität 11 angewendet werden wie in 2A–B dargestellt, so dass die Teilmenge von Cachewegen 251 zurückgestellt werden kann, um für Hardwarethreads nur geringer Priorität 11 verwendet zu werden. Geeigneterweise ist die Threadmaske geringer Priorität eine Abfolge von Bits, die ein Signal 220 erzeugt, die, wenn auf die Bits des Entscheidungssignals 241 der RPA 240 angewendet, die RPA 240 veranlassen, auf nur eine Teilmenge der Cachewege 251 zu weisen.
-
Geeigneterweise umfasst die Threadmaske geringer Priorität 230 ein oder mehrere (nicht gezeigte) Register zum Speichern der Maskierungsbits geringer Priorität. Das Anwenden einer vorbestimmten Threadmaske geringer Priorität 220 auf das Beispiel von 2B in der oben beschriebenen Weise resultiert darin, dass way_0 und way_1 nur für Hardwarethreads geringer Priorität 11 verfügbar gemacht werden. In dieser Weise wird eine Teilmenge 280 von Cachewegen umfassend way_0 und way_1 zurückgestellt, um nur für Hardwarethreads geringer Priorität 11 verwendet zu werden. Geeigneterweise werden sowohl eine Threadmaske 220 geringer Priorität als auch eine Threadmaske hoher Priorität 230 verwendet, so dass die Verwendung von zwei ausgewählten Teilmengen die Wahrscheinlichkeit verringert, dass Hardwarethreads geringer Priorität 11 gleichermaßen das Cacheteilsystem 105 mit Hardwarethreads hoher Priorität 11 nutzen, während zur selben Zeit sichergestellt wird, dass die Hardwarethreads geringer Priorität 11 nicht vollständig ausgeschlossen werden aufgrund der einen zuverlässigen Auswahl all der Cachewege 251 für Hardwarethreads hoher Priorität 11. Geeigneterweise ist entweder die Threadmaske geringer Priorität 220 oder die Threadmaske hoher Priorität 230 programmierbar, wie etwa über Anweisungen, die von einem menschlichen Benutzer empfangen wurden. Die Programmierung der Threadmasken geringer Priorität 220 und der Threadmaske hoher Priorität 230 ist abhängig vom besonderen Ersatzalgorithmus, der von der RPA 240 verwendet wird.
-
In einer anderen beispielhaften Ausgestaltung können die Threadmaske 220 geringer Priorität und die Threadmaske 230 hoher Priorität programmiert werden, so dass deren jeweiligen Teilmengen geringer Priorität und hoher Priorität wenigstens einen Cacheweg 251 gemeinsam nutzen, der genutzt werden kann, um sowohl Hardwarethreads 11 geringer Priorität als auch Hardwarethreads hoher Priorität 11 zu speichern. Beispielsweise ist es im Beispiel von 2B möglich, die Threadmaske geringer Priorität 220 und die Threadmaske hoher Priorität 230 in einer Weise zu programmieren, dass way_0 und way_1 sowohl von den Hardwarethreads geringer Priorität als auch hoher Priorität 11 genutzt werden, wobei way-2 und way-3 ausschließlich für die Hardwarethreads geringer Priorität 11 reserviert sind und way_4 bis way_7 ausschließlich für die Hardwarethreads hoher Priorität 11 reserviert sind. Geeigneterweise ist das Auswählen jeder Teilmenge geringer Priorität und hoher Priorität der Cachwege 251 programmierbar und wird auf der Basis pro Hardwarethread 11, basierend auf der empfangenen Thread ID 205, ausgeführt. Geeigneterweise ist eine Anzahl von Cachewegen 251, die für jede Teilmenge geringer Priorität und hoher Priorität ausgewählt wird, ebenso programmierbar.
-
Zurück zu 3 schreitet die Abfolge zu Block 330 fort, bei dem Hardwarethreads hoher Priorität 11 der Teilmenge von Cachewegen 251 zugeordnet wird, die in Block 320 ausgewählt wurden, um nur für Hardwarethreads hoher Priorität 11 verwendet zu werden. Als nächstes wird in Block 340 eine Cachenutzung eines Hardwarethreads hoher Priorität 11, wie etwa HT_1, der der Teilmenge von Cachewegen 251, die in Block 320 ausgewählt wurden, zugeordnet ist, überwacht, wie etwa durch ein Cachenutzungsüberwachungsteilsystem 210, das in 2A gezeigt ist, und in Zusammenhang mit 4 im Folgenden in größerem Detail beschrieben wird.
-
4 ist ein beispielhaftes Flussdiagramm, das in Zusammenhang mit 2A weiter den in Block 340 aus 3 dargestellten Überwachungsprozess darstellt. In 4 gezeigt beginnt das Verfahren bei Block 400 und schreitet zum Entscheidungsblock 410 fort, in dem das Cachenutzungsüberwachungsteilsystem 210 bestimmt, ob der zugeordnete Hardwarethread hoher Prioriät HT_1 in einem Status inaktiver Cachenutzung ist. Geeigneterweise weist das Cachenutzungsüberwachungsteilsystem 210 ein Hardwarethreadaktivitätsstatusteilsystem 212 auf, das in 2A gezeigt ist, das die Aktivitäten der Hardwarethreads hoher Priorität 11 basierend auf der Thread-ID 205, die vom Prozessor 106 empfangen wurde, überwacht. Wenn bestimmt wird, dass der Hardwarethread hoher Priorität HT_1 nicht in einem inaktiven Status ist (Entscheidungsblock 410), wird der Ablauf zu Entscheidungsblock 410 zurückgeführt und setzt sich in der vorgenannten Art in einer Schleife fort, bis der Hardwarethread hoher Priorität HT_1 vom Prozessor 106 verarbeitet worden ist.
-
Wenn bei Entscheidungsblock 410 bestimmt wird, dass der Hardwarethread hoher Priorität HT_1 in einem inaktiven Status ist, schreitet der Vorgang zu Block 420 fort, in dem ein Statuszeitintervall inaktiver Cachenutzung gemessen wird, welches die Zeit ist währenddessen der Hardwarethread hoher Priorität HT_1 im Status inaktiver Cachenutzung verbleibt. Der Vorgang schreitet dann zu Block 430 weiter, in dem das gemessene Zeitintervall mit einem vorbestimmten Inaktivitätscachenutzungsschwellenwert verglichen wird. Als nächstes wenn bei Entscheidungsblock 440 bestimmt wird, dass das gemessene Zeitintervall den vorbestimmten Inaktivitätscachenutzungsschwellenwert nicht überschreitet, wird der Vorgang zu Entscheidungsblock 410 rückgeführt. Wenn bestimmt wird, dass das gemessene Zeitintervall den vorbestimmten Cachenutzungsschwellenwert überschreitet (Entscheidungsblock 440), wird der Vorgang zu Block 340 von 3 zurückgeführt. Geeigneterweise ist das Messen des Statuszeitintervalls inaktiver Cachenutzung in Block 420 durch das Hardwarethreadaktivitätslogikteilsystem 211, das in 2A gezeigt ist, basierend auf den Zyklen eines Taktgebers (nicht gezeigt) ausgeführt. Das Hardwarethreadaktivitätslogikteilsystem 211 weist einen Zähler 213 zum Erhöhen eines Zählers basierend auf den gemessenen Zyklen des Taktgebers auf, wobei der Zähler der Zeitspanne entspricht, währenddessen ein Hardwarethread hoher Priorität 11, wie etwa HT_1, den Status inaktiver Cachenutzung beibehält. Geeigneterweise umfasst das gemessene Zeitintervall den Zähler. Das Hardwarethreadaktivitätslogikteilsystem 211 vergleicht dann das gemessene Zeitintervall mit dem vorbestimmten Inaktivitätscachenutzungsschwellenwert und bestimmt, ob das gemessene Zeitintervall den vorbestimmten Inaktivitätscachenutzungsschwellenwert übersteigt. Geeigneterweise kann das Hardwarethreadaktivitätslogikteilsystem 211 in einer Vielzahl von Software oder Hardwareausführungen ausgeführt sein.
-
Zurück zu 3 schreitet der Ablauf bei Block 350 fort, indem der Hardwarethread hoher Priorität HT_1 wieder einem anderen Cacheweg 251 zugeordnet wird, wenn basierend auf dem Ergebnis des Entscheidungsblocks 440 aus 4 bestimmt wird, dass die Cachenutzung des Hardwarethreads hoher Priorität HT_1 den vorbestimmten Inaktivitätscachenutzungsschwellenwert basierend auf dem Überwachen überschritten hat (z. B. wird bestimmt, dass die Inaktivitätszeitspanne von HT_1 eine akzeptable Zeitspanne überschreitet). Das Wiederzuordnen des zugeordneten Hardwarethreads hoher Priorität HT_1 weist dann das Deaktivieren der Threadmaske geringer Priorität 220 und der Threadmaske hoher Priorität 230 auf, wie etwa über Verändern eines Werts in jeweils deren Aktivierungsbits 221 und 231, wie in 2A gezeigt. Das Deaktivieren ermöglicht das erneute Zuordnen von HT_1 an einen anderen Cacheweg 251 ohne Einschränkungen der Teilmengen, die der Anwendung von Threadmasken geringer und hoher Priorität 220 und 230 unterliegen. Wie in 2A gezeigt, wird der Cacheweg 250, wie etwa way_0 aufnehmen HT_1, vom Hardwarethreadzuordnungsteilsystem 200 als Opferweg ausgewählt und für einen anderen Hardwarethread 11 verfügbar gemacht. Geeigneterweise überträgt das Hardwarethreadzuordnungsteilsystem 200 ein Opferwegsignal 201 an die Datenanordnung 250 und die Kennzeichnungsanordnung 260, um way_0 für einen anderen Hardwarethread verfügbar zu machen. Geeigneterweise bewahrt die Kennzeichnungsanordnung 260 eine Menge von Indizes 261, etwa wie index_0 bis index_n (n > 1), wobei jeder Index 261 einem Cacheweg 251 in der Datenanordnung 250 entspricht. HT_1 wird dann einem Cacheweg 251 von dem Hardwarethreadzuordnungsteilsystem 200 zugeordnet. Der Vorgang schreitet dann zu Block 370, in dem der gesamte Vorgang endet.
-
Zurück zum Entscheidungsblock 310, wenn bestimmt wird, dass ein oder mehrere Cachewege 251 einen Hardwarethread 11 nicht aufnehmen, schreitet der Vorgang zu Block 360 fort, indem Hardwarethreads hoher Priorität 11 den Cachewegen 251 zugeordnet werden, die Hardwarethreads 11 nicht aufnehmen. Geeigneterweise informiert die Statusanordnung 270 im Entscheidungsblock 310 das Hardwarethreadzuordnungsteilsystem 200, etwa über ein Signal 272, das ein oder mehrere Cachewege 251 einen Hardwarethread 11 nicht aufnehmen, so dass der Vorgang zu Block 360 fortschreiten kann. Als nächstes stellt die Statusanordnung 270 bei Block 360 dem Hardwarethreadzuordnungsteilsystem 200, wie etwa über ein Signal 273, Information über die Cachewege 258 bereit, die Hardwarethreads 11 nicht aufnehmen, basierend darauf, welchen Cachewegen 251, die Hardwarethreads nicht aufnehmen 11, das Hardwarethreadzuordnungsteilsystem 200 Hardwarethreads hoher Priorität 11 zuordnen. Der Vorgang schreitet dann zu Block 370, in dem der gesamte Vorgang endet. Es ist zu beachten, dass die Ausführungen in den Blöcken 310 und 260 entweder aufeinander folgend oder vor denjenigen in den Blöcken 320 bis 350 ausgeführt werden können, abhängig von der gewünschten Software oder von Überlegungen zur Hardwareausführung. Geeigneterweise weist die Multithreadprozessorumgebung 1 ein Speichermedium (nicht gezeigt) auf, die Software bereitstellt, die, wenn von einem Multiprozessorteilsystem 107 ausgeführt, das Multiprozessorteilsystem 107 veranlassen wird, die oben genannten Schritte von 3 und 4 auszuführen. Geeigneterweise ist das Speichermedium innerhalb des Multiprozessorteilsystems 107 ausgeführt.
-
5 ist ein Kreisdiagramm des Hardwarethreadzuordnungsteilsystems 200, das in 2 gezeigt ist. Die allgemeinen Arbeitsabläufe des Schaltkreises des Hardwarethreadzuordnungsteilsystems 200 werden nun in Bezug auf die oben genannten Arbeitsabläufe aus 3 und 4 beschrieben. Wie oben in Zusammenhang mit 2A und Block 320 von 3 beschrieben, weist ein Multithreadprozessorteilsystem 107 ein Cachewegauswahllogikteilsystem 202 zum Auswählen einer Teilmenge von Cachewegen 251 zum Speichern von Hardwarethreads 11, die als Hardwarethreads hoher Priorität 10 zum Verarbeiten durch einen Prozessor 106 identifiziert wurden, auf. Wie in 5 gezeigt, kann das Cachewegauswahllogikteilsystem 202 als Eingabe die Abfolge von Bits der Threadmaske hoher Priorität (HPM) 230, die ein Signal 232 erzeugt und die Abfolge von Bits der Threadmaske geringer Priorität (LPM) 220, die ein Signal 222 erzeugt, empfangen. Die Signale 222 und 232 werden dann im Multiplexer 500 empfangen, der Threadmasken hoher Priorität oder geringer Priorität 230 oder 220 auswählt. Geeigneterweise basiert die Auswahl durch den Multiplexer 500 auf dem empfangenen Thread ID Signal, das die Art geringer oder hoher Priorität der Anfrage von einem Hardwarethread 11 anzeigt. Das ausgewählte Signal wird dann über das UND-Gatter 510 auf die Bits des Entscheidungssignals 245 der RA 240 angewendet, wodurch die RPA 240 veranlasst wird, nur auf eine Teilmenge der Cachewege 251 zu verweisen.
-
Das resultierende Signal 511 wird dann vom Cachewegauswahllogikteilsystem 202 an den Multiplexer 520 ausgegeben, der dann die ursprüngliche Auswahl der Cachewege 251 durch die RPA 240, wie durch Signal 241 angezeigt, oder die angepasste Auswahl der Cachewege 251 durch Anwenden einer der Threadmasken hoher Priorität oder geringer Priorität 230 oder 220, wie durch Signal 511 angezeigt, auswählt. Die Auswahl wird basierend auf den empfangenen Aktivierungs (EN) Signal 521 durchgeführt, das anzeigt, ob entweder die Threadmaske hoher Priorität oder die Threadmaske geringer Priorität 230 oder 220 aktiviert wurde. Wie oben in Zusammenhang mit Block 350 aus 3 beschrieben, hängt die Entscheidung zum Deaktivieren der Threadmaske hoher Priorität oder geringer Priorität 230 oder 220 auf den Wiederzuordnungsbestimmungen zum zugeordneten Hardwarethread hoher Priorität 11, wie etwa HT_1 ab. Als nächstes wird die Ausgabe des Multiplexers 520 in einen Opferwegbestimmungslogikblock 530 eingegeben um zu bestimmen, welcher der Cachewege 251 verwendet werden kann, um einen eingehenden Hardwarethread aufzunehmen. Geeigneterweise kann der Opferwegbestimmungslogikblock 530 in einer Reihe von Software- oder Hardware-Ausgestaltungen ausgeführt sein. Die Cachewege 251 Bestimmungen hängen davon ab, ob die Auswahl basierend auf der ursprünglichen Auswahl der Cachewege 251 durch die RPA 240 oder die angepasste Auswahl der Cachewege 251, wie durch den Multiplexer 520 ausgewählt, basierend auf dem Aktivierungssignal 521, gemacht wurde. Die Ausgabe des Opferwegbestimmungslogikblocks 530 wird dann in den Multiplexer 540 eingegeben.
-
Der Multiplexer 540 wählt dann, in einer oben in Zusammenhang mit Entscheidungsblock 310 aus 3 beschriebenen Weise, zwischen einem Opferweg 530, der mittels des oben genannten Vorgangs bestimmt wurde, entsprechend den Blöcken 320 bis 350 von 3 oder einem Opferweg 273, der darauf basierend bestimmt wurde, ob ein Cacheweg 251 einen Hardwarethread 11 nicht aufnimmt. Das Auswahlsignal 272 von der Statusanordnung 270 bestimmt die von dem Multiplexer 540 vorgenommene Auswahl. Wie oben in Zusammenhang mit den Blöcken 310 und 360 aus 3 beschrieben, wenn ein Cacheweg 251 einen Hardwarethread 11 nicht aufnimmt, wird jeder Cacheweg 251 ausgewählt und daher wählt der Multiplexer 540 die Eingabe 273 von der Statusanordnung als seine Ausgabe. Ansonsten wird Eingabe 531 ausgewählt. Wie oben bemerkt, kann der Arbeitsablauf des Multiplexers 540 vor oder zu jedem Zeitpunkt auf diejenigen des Cachewegeauswahllogikteilsystems 550 ausgeführt werden, abhängig von der gewünschten Software oder von Überlegungen zur Hardwareausgestaltung.
-
Es sollte beachtet werden, dass verschiedene Merkmale der vorliegenden Ausgestaltungen lediglich zur Klarheit der Beschreibung separat diskutiert wurden und dass diese als Gesamtheit oder teilweise in einzelne Ausgestaltungen der Erfindung aufgenommen werden können, die alle oder einige dieser Merkmale haben.
