DE102010054337B4 - Mechanismen, um ineffizientes Core-Hopping zu vermeiden und Hardware-unterstützte Auswahl eines Niedrigleitungszustands bereitzustellen - Google Patents

Abstract

Vorrichtung, umfassend: eine Vielzahl von N Prozessorkernen (301–304); einer Core-Hopping-Hardware, um einen oder mehrere Hardware-Thread-Kontexte von einem Kern zu einem anderen Kern zu migrieren; einem Aktivitätsmonitor (430), um Informationen über derzeitige oder vergangene Leistungszustände der N Kerne zu empfangen und um Daten in einem Aufzeichnungsintervall aufzuzeichnen, die anzeigen, wann und wie lange sich jeder Kern in einem bestimmten Leistungszustand befand; einen Prädiktor (435), der die während eines Aufzeichnungsintervalls aufgezeichneten Daten verwendet, um Verweilzeiten für Musterverteilungen von Kern-Leistungszuständen der N Prozessorkerne für das nächste Aufzeichnungsintervall vorherzusagen, einen Core-Hop-Manager (440), der basierend auf den vorhergesagten Verweilzeiten der Musterverteilungen im nächsten Aufzeichnungsintervall eine Migration eines Hardware-Kontexts von einem der Prozessorkerne zu einem anderen auf eine Anfrage hin als für eine Wärmeabfuhr effizient erlaubt oder als ineffizient verweigert.

Description

• TECHNISCHES GEBIET
• Diese Erfindung betrifft das Gebiet von Prozessorausführung und insbesondere ein Optimieren des Prozessorbetriebs.
• HINTERGRUND
• Fortschritte bei Halbleiterverarbeitung und Logikdesign haben eine Zunahme der Menge an Logik erlaubt, die auf Geräten mit integrierter Schaltung vorliegen kann. Demzufolge haben sich Konfigurationen von Computersystemen von einer einzelnen oder mehreren integrierten Schaltungen in einem System zu mehreren Prozessor-Dies, mehreren Kernen, mehreren Hardware-Threads und mehreren logischen Prozessoren entwickelt, die auf individuellen integrierten Schaltungen vorliegen. Ein Prozessor oder eine integrierte Schaltung umfasst typischerweise einen einzelnen physikalischen Prozessor-Die, wobei der Prozessor-Die jegliche Anzahl an Kernen, Hardware-Threads oder logischen Prozessoren beinhalten kann.
• Die immer größer werdende Anzahl an Verarbeitungselementen – Kernen, Hardware-Threads und logischen Prozessoren – auf integrierten Schaltungen ermöglicht, dass mehr Tasks parallel umgesetzt werden können. Als logische Folge der erhöhten Rechenleistung jedoch, haben sich ebenfalls die Probleme mit thermischer Dichte und Verlustleistung verstärkt. Demzufolge können Prozessoren mit mehreren Kernen eine Wärmeabfuhrtechnik namens Core-Hopping einsetzen – ein Verschieben zumindest eines Architekturzustands/-kontextes eines Kerns zu einem anderen Kern. Mit einem Verschieben eines gesamten Kontextes von einem Kern zu einem anderen gehen jedoch die Kosten dafür einher – verschwendete Ausführungszyklen, auf das Verschieben verwandte Energie und kalte Caches. Bislang gibt es noch keine intelligente Entscheidung darüber, wann basierend auf thermischer Dichte außerhalb der anfänglichen Core-Hop-Entscheidung ein Core-Hop durchgeführt werden soll. Demzufolge kann ein Core-Hop initiiert werden, wenn ein Core-Hop nicht benötigt wird – eine auslösende thermische Dichte-Bedingung kann selbsterleichternd sein – oder kann nicht machbar sein – der Hop führt zu denselben oder schlechteren thermischen Bedingungen. Als Folge gibt es einige Umstände, bei denen ein Core-Hop aufgrund thermischer Bedingungen ausgelöst wird, aber es ist vorteilhaft, den Core-Hop zu vermeiden.
• Da die Bedenken bezüglich Wärme und Leistung für Prozessoren weiter steigen, wird die intelligente Verwendung von Niedrigleistungszuständen wichtiger. Derzeit ist eine heutige Software auf privilegiertem Level – Betriebssysteme – nicht sonderlich genau, wenn ein Übergang in Niedrigleistungszustände angefragt wird. Demzufolge kann frühere Software einen Kern anfragen, in einen spezifischen Niedrigleistungszustand einzutreten, der sowohl ineffizient ist, da er zu tief ist – es wird weniger Leistung verbraucht, aber nicht ausreichend Aufwachzeit im Vergleich zu der Menge an Zeit, während der der Kern sich in Zukunft im Leerlauf befindet – oder zu niedrig – es wird mehr Leistung verbraucht, wenn die Leerlaufzeit größer als die Aufwachzeit ist.
• Der Artikel „Dynamic Thermal Management in 3D Multicore Architectures” von A. Coskun et al. aus „Proceedings of the Design, Automation and Test in Europe Conference (DATE '09), 20–24 April 2009, Seiten 1410–1415 offenbart Untersuchungen, wie thermisches Management, Leistungsmanagement, und Jobplanungsmethoden das thermische Verhalten von 3D-Chips beeinflussen. Es wird eine dynamische, das thermische Verhalten berücksichtigende Job-Planungstechnik für 3D-Systeme vorgeschlagen, um thermische Probleme bei sehr niedrigem Leistungsaufwand zu reduzieren. Der Ansatz kann auch in Leistungsmanagementmethoden integriert werden, um den Energieverbrauch zu reduzieren, wobei thermische Hotspots und starke Temperaturschwankungen vermieden werden.
• Die US 2009/0064164 A1 offenbart ein Verfahren zum Ausgleichen der Task-Ausführung in Multithreadprozessoren, um Hotspots zu minimieren. Der thermische Ausgleich kann Simultaneous-Multithreading(SMT)-Wärmeausgleich, Chiplevel-Multiprocessor-(CMP)-Wärmeausgleich sowie die Verzögerung der Ausführung von identifizierten Hot-Tasks, das Migrieren von identifizieren Hot-Tasks von einem Kern zu einem kälteren Kern, nutzerspezifiziertes Core-Hopping und SMT-Hardware-Threading umfassen.
• Es ist die Aufgabe der vorliegenden Erfindung, eine Vorrichtung bereitzustellen, mit der ein effizientes Core-Hopping ermöglicht wird, sowie ein entsprechendes Verfahren.
• Die Aufgabe wird gelöst mit einer Vorrichtung mit den Merkmalen gemäß dem Hauptanspruch sowie ein Verfahren mit den Merkmalen gemäß Anspruch 18.
• Ausführungsformen der Erfindung sind in den Unteransprüchen angegeben.
• KURZE BESCHREIBUNG DER ZEICHNUNGEN
• Die vorliegende Erfindung wird beispielhaft veranschaulicht und soll durch die Figuren der begleitenden Zeichnungen nicht eingeschränkt werden.
• 1 veranschaulicht eine Ausführungsform eines Prozessors einschließlich mehrerer Verarbeitungselemente.
• 2 veranschaulicht eine weitere Ausführungsform eines Prozessors einschließlich mehrerer Verarbeitungselemente.
• 3 veranschaulicht eine Ausführungsform von Mechanismen, um ineffizientes Core-Hopping zu vermeiden.
• 4 veranschaulicht eine Ausführungsform eines Vorhersagemechanismus von 3, um zukünftige Aktivität vorherzusagen.
• 5 veranschaulicht eine Ausführungsform, um Residenz von Leerlauf-Aktivitätsmustern zur Vorhersage zukünftiger Aktivität einzusetzen.
• 6 veranschaulicht eine Ausführungsform, um ein Ablaufdiagramm für ein Verfahren zum Vermeiden eines ineffizienten Core-Hops vorab abzurufen.
• 7 veranschaulicht eine Ausführungsform, um Hardware-unterstützte Auswahl eines Niedrigleistungszustands bereitzustellen.
• 8 veranschaulicht eine weitere Ausführungsform, um Hardware-unterstützte Auswahl eines Niedrigleistungszustands bereitzustellen.
• 9a veranschaulicht eine Ausführungsform eines Ablaufdiagrammes für ein Verfahren zum Bereitstellen von Hardware-unterstützter Auswahl eines Niedrigleistungszustands.
• 9b veranschaulicht eine Ausführungsform einer Zustandsmaschine für eine vorhergesagte Leerlaufzustandsmaschine von 8.
• AUSFÜHRLICHE BESCHREIBUNG
• In der folgenden Beschreibung werden zahlreiche spezifische Details angeführt, wie z. B. Beispiele spezifischer Hardwarestrukturen/-mechanismen zur Leerlauf-Aktivitäts-Vorhersage, Messung einer Leerlaufdauer, Genauigkeitsbestimmung; spezifische Prozessorkonfigurationen, spezifische Core-Hop-Bedingungen, spezifische Niedrigleistungszustände, spezifische Prozessoreinheiten/-logik, spezifische Beispiele von Verarbeitungselementen etc., um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Für einen Fachmann ist es jedoch offensichtlich, dass diese spezifischen Details nicht eingesetzt werden müssen, um die vorliegende Erfindung zu betreiben. In anderen Fällen wurden wohlbekannte Komponenten oder Verfahren, wie z. B. spezifische und alternative Mehrkern- und Multi-Thread-Prozessorarchitekturen, spezifische Logikschaltungen für veranschaulichte Module/Blöcke und spezifische Betriebsdetails von Mikroprozessoren nicht im Detail beschrieben, um die vorliegende Erfindung nicht unnötig in den Hintergrund treten zu lassen.
• Das hierin beschriebene Verfahren und die Vorrichtung dienen dazu, ineffizientes Core-Hopping zu vermeiden, und eine Hardware-unterstützte Auswahl eines Niedrigleistungszustands bei einem Prozessor bereitzustellen. Speziell werden diese Optimierungen primär mit Bezug auf Hopping und Auswahl eines Leistungszustands basierend auf vorhergesagter, zukünftiger Aktivität oder Inaktivität von Kernen bei einem Prozessor erörtert. In der Tat ist eine veranschaulichende Ringorganisation zur Kommunikation zwischen Prozessorkernen nachstehend kurz mit Bezug auf 2 beschrieben, um eine Ausführungsform einer potentiellen Konfiguration auf einem Prozessorkern zu veranschaulichen. Dennoch sind die hierin beschriebenen Vorrichtungen und Verfahren nicht dahingehend eingeschränkt, als dass sie in jeglicher integrierten Schaltung unter Einsatz von Kontext-Hopping oder Auswahl eines Leistungszustands für getrennte Teile der integrierten Schaltung implementiert sein können.
• Ausführungsformen von Mehrkernprozessoren
• Bezugnehmend auf 1 ist eine Ausführungsform eines Prozessors einschließlich mehrerer Kerne veranschaulicht. Prozessor 100 beinhaltet bei einer Ausführungsform Core-Hopping-Hardware – nicht gezeigt – um Kontexte zwischen Kernen zu verschieben. Bei einer weiteren Ausführungsform beinhaltet Prozessor 100 Leistungs-Hardware – nicht gezeigt – um Kerne individuell in Niedrigleistungszustände zu setzen. Prozessor 100 beinhaltet jeglichen Prozessor, wie z. B. einen Mikroprozessor, einen eingebetteten Prozessor, einen digitalen Signalprozessor (digital signal processor, DSP), einen Netzwerkprozessor oder ein anderes Gerät, um Code auszuführen. Prozessor 100, wie veranschaulicht, beinhaltet eine Vielzahl an Verarbeitungselementen.
• Bei einer Ausführungsform bezieht sich ein Verarbeitungselement auf eine Thread-Einheit, ein Thread-Fenster, eine Prozess-Einheit, einen Kontext, einen logischen Prozessor, einen Hardware-Thread, einen Kern und/oder jedes andere Element, das einen Zustand für einen Prozessor enthalten kann, wie z. B. einen Ausführungszustand oder Architekturzustand. Mit anderen Worten bezieht sich ein Verarbeitungselement bei einer Ausführungsform auf jede Hardware, die unabhängig mit Code verbunden sein kann, wie z. B. ein Software-Thread, Betriebssystem, eine Anwendung oder ein anderer Code. Ein physikalischer Prozessor bezieht sich typischerweise auf eine integrierte Schaltung, die potentiell jegliche Anzahl anderer Verarbeitungselemente beinhaltet, wie z. B. Kerne oder Hardware-Threads.
• Ein Kern bezieht sich oft auf Logik, die sich auf einer integrierten Schaltung befindet, die einen unabhängigen Architekturzustand aufrechterhalten kann, wobei jeder unabhängig aufrechterhaltene Architekturzustand mit zumindest einigen dedizierten Ausführungsressourcen verbunden ist. Im Gegensatz zu Kernen bezieht sich ein Hardware-Thread typischerweise auf jegliche Logik, die sich auf einer integrierten Schaltung befindet, die einen unabhängigen Architekturzustand aufrechterhalten kann, wobei die unabhängig aufrechterhaltenen Architekturzustände Zugang zu Ausführungsressourcen gemeinsam benutzen. Es ist ersichtlich, dass die Linie zwischen der Nomenklatur eines Hardware-Threads und Kerns überlappt, wenn bestimmte Ressourcen gemeinsam benutzt werden und andere einem Architekturzustand fest zugeordnet sind. Dennoch werden ein Kern und ein Hardware-Thread oftmals von einem Betriebssystem als individuelle logische Prozessoren angesehen, wobei das Betriebssystem Operationen auf jedem logischen Prozessor individuell schedulen kann.
• Physikalischer Prozessor 100, wie in 1 veranschaulicht, beinhaltet zwei Kerne, Kern 101 und 102. Hier kann Core-Hopping eingesetzt werden, um thermische Bedingungen auf einem Teil eines Prozessors zu erleichtern. Hopping von Kern 101 zu 102 kann jedoch potentiell dieselben thermischen Bedingungen auf Kern 102 erzeugen, die auf Kern 101 bestanden, während die Kosten eines Core-Hops anfallen. Daher beinhaltet Prozessor 100 bei einer Ausführungsform jegliche Anzahl an Kernen, die Core-Hopping einsetzen können. Des Weiteren kann in Prozessor 100 beinhaltete Power-Management-Hardware in der Lage sein, individuelle Einheiten und/oder Kerne in Niedrigleistungszustände zu setzen, um Energie zu sparen. Hier stellt bei einer Ausführungsform Prozessor 100 Hardware bereit, um bei einer Auswahl eines Niedrigleistungszustands für Verarbeitungselemente von Prozessor 100, sowie potentiell für individuelle Module/Einheiten zu helfen, die nachstehend ausführlicher veranschaulicht und erörtert werden.
• Obwohl Prozessor 100 asymmetrische Kerne beinhalten kann, d. h. Kerne mit unterschiedlichen Konfigurationen, funktionalen Einheiten und/oder Logik, sind symmetrische Kerne veranschaulicht. Demzufolge wird Kern 102, der als mit Kern 101 identisch veranschaulicht ist, nicht im Detail erörtert, um eine wiederholende Erörterung zu vermeiden. Zusätzlich beinhaltet Kern 101 zwei Hardware-Threads 101a und 101b, während Kern 102 zwei Hardware-Threads 102a und 102b beinhaltet. Daher sehen Software-Entitäten, wie z. B. ein Betriebssystem, Prozessor 100 potentiell als vier getrennte Prozessoren an, d. h. vier logische Prozessoren oder Verarbeitungselemente, die vier Software-Threads gleichzeitig ausführen können. Bei einer Ausführungsform bezieht sich Hopping von Kontexten auf Core-Hopping; bei anderen Ausführungsformen jedoch kann Thread-Hopping entweder getrennt von oder in Verbindung mit Core-Hopping durchgeführt werden.
• Hier wird ein erster Thread mit Architekturzustandsregistern 101a verbunden, ein zweiter Thread wird mit Architekturzustandsregistern 101b verbunden, ein dritter Thread wird mit Architekturzustandsregistern 102a verbunden, und ein vierter Thread wird mit Architekturzustandsregistern 102b verbunden. Wie veranschaulicht, sind Architekturzustandsregister 101a in Architekturzustandsregistern 101b wiederholt, sodass individuelle Architekturzustände/-kontexte für logischen Prozessor 101a und logischen Prozessor 101b gespeichert werden können. Weitere kleinere Ressourcen, wie z. B. Befehlszeiger und Umbenennungslogik in Umbenennungszuordnerlogik 130, können ebenfalls für Threads 101a und 101b wiederholt werden. Einige Ressourcen, wie z. B. Neuordnungspuffer in Neuordnungs-/Rückordnungseinheit 135, ILTB 120, Load-/Speicher-Puffer und Warteschlangen können durch Partitionierung gemeinsam benutzt werden. Weitere Ressourcen, wie z. B. interne Universalregister, Seitentabellen-Basisregister, untergeordneter Daten-Cache und Daten-TLB 115, Ausführungseinheit(en) 140 und Teile von Out-of-Order-Einheit 135 werden potentiell vollständig gemeinsam benutzt.
• Prozessor 100 beinhaltet oftmals weitere Ressourcen, die vollständig gemeinsam benutzt werden können, durch Partitionierung gemeinsam benutzt werden können oder von Verarbeitungselementen/an Verarbeitungselemente fest zugeordnet sein können. In 1 ist eine Ausführungsform eines rein beispielhaften Prozessors mit veranschaulichenden logischen Einheiten/Ressourcen eines Prozessor veranschaulicht. Es ist zu beachten, dass ein Prozessor jegliche dieser funktionalen Einheiten beinhalten oder weglassen kann, sowie jegliche andere bekannte funktionale Einheiten, Logik oder Firmware, die nicht dargestellt sind, beinhalten kann. Wie veranschaulicht beinhaltet Prozessor 100 einen Zweigzielpuffer 120, um Zweige vorherzusagen, die ausgeführt/genommen werden sollen, und einen Befehlsübersetzungspuffer (instruction-translation buffer, I-TLB) 120, um Adressübersetzungseinträge für Befehle zu speichern.
• Prozessor 100 beinhaltet weiter Dekodierungsmodul 125, das mit Abrufeinheit 120 gekoppelt ist, um abgerufene Elemente zu dekodieren. Bei einer Ausführungsform ist Prozessor 100 mit einer Befehlssatzarchitektur (Instruction Set Architecture, ISA) verbunden, die auf Prozessor 100 ausführbare Befehle definiert/spezifiziert. Hier beinhalten von der ISA erkannte Maschinencodebefehle oftmals einen Teil des Befehls, der als ein Befehlscode bezeichnet wird, der einen durchzuführenden Befehl oder eine Operation referenziert/spezifiziert.
• Bei einem Beispiel beinhaltet Zuordner- und Umbenennerblock 130 einen Zuordner, um Ressourcen zu reservieren, wie z. B. Registerdateien, um Befehlsverarbeitungsergebnisse zu speichern. Threads 101a und 101b sind jedoch potentiell zu einer Out-of-Order-Ausführung in der Lage, wobei Zuordner- und Umbenennerblock 130 ebenfalls weitere Ressourcen, wie z. B. Neuordnungspuffer, reserviert, um Befehlsergebnisse nachzuverfolgen. Einheit 130 kann ebenfalls einen Registerumbenenner beinhalten, um Programm-/Befehlsreferenzregister auf andere Register innerhalb von Prozessor 100 umzubenennen. Neuordnungs-/Rückordnungseinheit 135 beinhaltet Komponenten, wie z. B. die vorstehend genannten Neuordnungspuffer, Load-Puffer und Speicher-Puffer, um Out-of-Order-Ausführung und spätere In-Order-Rückordnung Out-of-Order ausgeführter Befehle zu unterstützen.
• Scheduler- und Ausführungseinheit(en)block 140 beinhaltet bei einer Ausführungsform eine Scheduler-Einheit, um Befehle/Operationen auf Ausführungseinheiten zu schedulen. Beispielsweise wird ein Gleitkommabefehl auf einem Port einer Ausführungseinheit gescheduled, die eine verfügbare Gleitkomma-Ausführungseinheit aufweist. Mit den Ausführungseinheiten verbundene Registerdateien sind ebenfalls beinhaltet, um Verarbeitungsergebnisse von Informationsbefehlen zu speichern. Beispielhafte Ausführungseinheiten beinhalten eine Gleitkomma-Ausführungseinheit, eine Ganzzahl-Ausführungseinheit, eine Sprung-Ausführungseinheit, eine Load-Ausführungseinheit, eine Speicher-Ausführungseinheit und andere bekannte Ausführungseinheiten.
• Untergeordneter Daten-Cache und Datenübersetzungspuffer (data translation buffer, D-TLB) 150 sind mit Ausführungseinheit(en) 140 gekoppelt. Der Daten-Cache soll kürzlich verwendete/betriebene Elemente, wie z. B. Daten-Operanden, speichern, die potentiell in Speicher-Kohärenzzuständen enthalten sind. Der D-TLB soll kürzlich virtuell/linear zu physikalischen Adressübersetzungen speichern. Als spezifisches Beispiel kann ein Prozessor eine Seitentabellenstruktur beinhalten, um physikalischen Speicher in eine Vielzahl virtueller Seiten aufzubrechen.
• Wie dargestellt benutzen Kerne 101 und 102 Zugriff auf übergeordneten oder weiter entfernten Cache 110 gemeinsam, derkürzlich abgerufene Elemente in den Cache-Speicher aufnehmen soll. Es ist zu beachten, dass übergeordnet oder weiter entfernt sich auf Cache-Level bezieht, die zunehmen oder sich weiter von der/den Ausführungseinheit(en) entfernen. Bei einer Ausführungsform ist übergeordneter Cache 110 ein Last-Level-Daten-Cache – letzter Cache in der Speicherhierarchie auf Prozessor 100 – wie z. B. ein Daten-Cache zweiter oder dritter Ebene. Übergeordneter Cache 110 ist jedoch nicht dahingehend eingeschränkt, dass er mit einem Befehls-Cache verbunden sein oder ihn beinhalten kann. Ein Trace-Cache – ein Typ eines Befehls-Caches – kann stattdessen hinter Decoder 125 gekoppelt sein, um kürzlich dekodierte Traces zu speichern.
• Bei der dargestellten Konfiguration ist zu beachten, dass Prozessor 100 ebenfalls Busschnittstellenmodul 105 beinhaltet, um mit Geräten außerhalb von Prozessor 100 zu kommunizieren, wie z. B. Systemspeicher 175, einem Chipsatz, einer Northbridge oder einer anderen integrierten Schaltung. Speicher 175 kann Prozessor 100 fest zugeordnet sein oder mit anderen Geräten in einem System gemeinsam benutzt werden. Herkömmliche Beispiele von Typen von Speicher 175 beinhalten dynamischen Direktzugriffsspeicher (dynamic random access memory, DRAM), statischen RAM (static RAM, SRAM), Permanentspeicher (non-volatile memory, NV memory) und andere bekannte Speichergeräte.
• 1 veranschaulicht eine abstrahierte, logische Ansicht eines beispielhaften Prozessors mit einer Darstellung unterschiedlicher Module, Einheiten und/oder Logik. Es ist jedoch zu beachten, dass ein die hierin beschriebenen Verfahren und Vorrichtungen einsetzender Prozessor die veranschaulichten Einheiten nicht beinhalten muss. Und der Prozessor kann einige oder alle der gezeigten Einheiten weglassen. Um das Potential für eine unterschiedliche Konfiguration zu veranschaulichen, wendet sich die Erörterung nun 2 zu, die eine Ausführungsform von Prozessor 200 einschließlich eines sich auf dem Prozessor befindlichen Speicherschnittstellenmoduls – ein Uncore-Modul – mit einer Ringkonfiguration darstellt, um mehrere Kerne zu verbinden. Prozessor 200 ist einschließlich eines physikalisch verteilten Caches; einer Ring-Kopplungsstruktur; sowie Kern-, Cache- und Memory-Controller-Komponenten veranschaulicht. Diese Darstellung ist jedoch rein veranschaulichend, da ein Prozessor, der die beschriebenen Verfahren und Vorrichtungen implementiert, jegliche Verarbeitungselemente, Art oder Ebene an Cache und/oder Speicher, Front-Side-Bus oder eine andere Schnittstelle zur Kommunikation mit externen Geräten beinhalten kann.
• Bei einer Ausführungsform sollen Caching-Agenten 221–224 jeweils eine Scheibe eines physikalisch verteilten Cache verwalten. Als Beispiel soll jede Cache-Komponente, wie z. B. Komponente 221, eine Scheibe eines Caches für einen kollokierten Kern verwalten – ein Kern mit dem der Cache-Agent verbunden ist, um die verteilte Scheibe des Caches zu verwalten. Wie dargestellt, werden Cache-Agenten 221–224 als Cachescheiben-Schnittstellenlogiken (Cache Slice Interface Logics, CSILs) bezeichnet; sie können ebenfalls als Cache-Komponenten, Agenten oder andere bekannte Logik, Einheiten oder Module bezeichnet werden, um eine Schnittstelle mit einem Cache oder einer Scheibe davon zu bilden. Es ist zu beachten, dass der Cache jegliche Ebene eines Caches sein kann; dennoch konzentriert sich die Erörterung für diese beispielhafte Ausführungsform auf einen Last-Level-Cache (LLC), der von Kernen 201–204 gemeinsam benutzt wird.
• Ganz wie Cache-Agenten Traffic auf Ring-Kopplungsstruktur 250 verarbeiten und eine Schnittstelle mit Cache-Scheiben bilden, sollen Kernagenten/-komponenten 211–214 Traffic verarbeiten bzw. mit Kernen 201–204 eine Schnittstelle bilden. Wie dargestellt werden Kernagenten 221–224 als Prozessorkern-Schnittstellenlogiken (Processor Core Interface Logics, PCILs) bezeichnet; sie können ebenfalls als Kernkomponenten, Agenten oder andere bekannte Logik, Einheiten oder Module bezeichnet werden, um eine Schnittstelle mit einem Verarbeitungselement zu bilden. Zusätzlich ist Ring 250 als Memory-Controller-Schnittstellenlogik (Memory Controller Interface Logic, MCIL) 230 und Grafik-Hub (Graphics Hub, GFX) 240 beinhaltend gezeigt, um mit anderen Modulen, wie z. B. Memory-Controller (IMC) 231 und einem Grafikprozessor (nicht veranschaulicht), eine Schnittstelle zu bilden. Ring 250 kann jedoch jegliche der vorstehend genannten Module beinhalten oder weglassen, sowie andere bekannte Prozessormodule, die nicht veranschaulicht sind, beinhalten. Zusätzlich können ähnliche Module mittels anderer bekannter Kopplungsstrukturen, wie z. B. einer Punkt-zu-Punkt-Kopplungsstruktur oder einer Mehrpunkt-Kopplungsstruktur, verbunden sein.
• Ausführungsformen, um ineffiziente Core-Hops zu vermeiden
• Bei einer Ausführungsform soll ein Prozessor, wie z. B. der in 1 veranschaulichte Prozessor, in 2 veranschaulichte Prozessor oder ein anderer, nicht veranschaulichter Prozessor, ineffiziente Core-Hops vermeiden. Wendet man sich 3 zu, ist eine Ausführungsform eines Prozessors veranschaulicht, der solch ineffiziente Core-Hops vermeiden kann. Bei dieser Veranschaulichung bezieht sich ein Core-Hop auf eine Verschiebung eines Kontextes oder Architekturzustands von einem Kern, wie z. B. Kern 302, zu einem anderen Kern, wie z. B. Kern 303. Core-Hop-Auslösemechanismus 310 soll, basierend auf jeglichen bekannten Bedingungen für einen Core-Hop, einen Core-Hop oder ein Core-Hop-Ereignis auslösen. Beispielsweise kann ein Core-Hop basierend auf einer thermischen Dichte-Bedingung ausgelöst werden. Mit anderen Worten, wenn ein Teil eines Prozessors, oder spezifischer ein Kern eines Prozessors, zu heiß ist, dann kann ein Core-Hop bei einigen Szenarios in der Lage sein, die thermische Dichte-Bedingung zu erleichtern – die Auslastung und entsprechend die Wärme auf andere physikalische Orte des Prozessors verteilen.
• Als spezifisches veranschaulichendes Beispiel wird davon ausgegangen, dass Kerne 301 und 302 auf einem Prozessor angeordnet sind und bei voller Kapazität arbeiten, was zur Generierung von zuviel Wärme auf einem Teil eines Prozessors führt – einer thermischen Dichte-Bedingung. Basierend auf irgendeiner bekannten Vorrichtung oder einem Verfahren, um solch eine Bedingung anzuzeigen, generiert/löst Core-Hop-Auslöselogik 310 eine Core-Hop-Anfrage aus. In Antwort auf die Anfrage kann ein Core-Hop-Mechanismus/-Manager einen Core-Hop durchführen. Bei diesem Szenario kann Core-Hop-Mechanismus 320 eine Migration des Architekturzustands von Kern 301 initiieren, was beinhalten kann, ein oder mehr oder potentiell alle Hardware-Thread-Kontexte auf Kern 301 zu einem anderen Kern, wie z. B. Kern 304, zu migrieren. Demzufolge wird die Auslastung des Prozessors über den Prozessor verteilt, was potentiell ebenfalls die Wärme verteilt.
• Einen Core-Hop wie vorstehend lediglich auf derzeitigen Wärmeinformationen ohne einige zusätzliche Informationen hinsichtlich zukünftiger Aktivitätsvorhersage durchzuführen, führt jedoch potentiell dazu, dass ineffiziente Core-Hops erlaubt werden. Als Beispiel kann Kern 301 bei vorstehender Situation planen, während eines nächsten Intervalls im Leerlauf zu sein, was zu einer Selbsterleichterung der thermischen Dichte-Bedingung führen würde; der Leerlauf würde nicht viel Wärme generieren. Dennoch fallen ohne Vorhersage sowohl Kosten bei Leistung als auch verschwendeter Ausführungszeit für den Core-Hop an, wenn dieser durch Vorhersage des zukünftigen Leerlaufs hätte vermieden werden können. Bei einem weiteren Beispiel weisen drei der vier veranschaulichten Kerne – 301, 302 und 304 – beträchtliche Auslastungen auf, die eine thermische Dichte-Bedingung hervorrufen, die zu einem Core-Hop führen würde. Einen Kontext eines beschäftigten Kerns jedoch zu Kern 303 zu hoppen, kann die thermische Dichte-Bedingung aufgrund der Nähe von Kern 303 zu den anderen Kernen, die noch beschäftigt sind, jedoch nicht erleichtern.
• Daher soll bei einer Ausführungsform Vorhersagemechanismus 315 zukünftige Aktivität der Vielzahl an Prozessorkernen für ein zukünftiges Intervall vorhersagen. Ein Intervall wie hierin bezeichnet, kann sich auf eine Menge an Zeit, eine Anzahl an Ausführungszyklen oder jegliche andere zeitliche Messung beziehen. Beispielsweise kann das Intervall von einigen Zyklen zu einigen tausend Mikrosekunden reichen. Ebenso kann jedes bekannte Verfahren zum Vorhersagen von Aktivität eines Prozessors, Kerns, Verarbeitungselements oder eine andere Ausführungs-Engine eingesetzt werden, um die Aktivität von Prozessorkernen 301–304 während eines zukünftigen/nächsten Intervalls vorherzusagen. Verallgemeinerte, veranschaulichende Beispiele solch einer Vorhersage beinhalten: Einsetzen einer vergangenen Aktivität der Vielzahl an Prozessorkernen während eines früheren Intervalls als die zukünftige Aktivität der Vielzahl an Prozessorkernen für das zukünftige Intervall; Empfangen eines Aktivitätshinweises von einer Software-Entität und Vorhersagen zukünftiger Aktivität basierend auf dem Aktivitätshinweis, der eine arithmetische oder statistische Vorhersage zukünftiger Aktivität durchführt; Einsetzen eines Vorhersagealgorithmus, wie z. B. einem Kalman-Filteralgorithmus, um die zukünftige Aktivität vorherzusagen; und Einsetzen vergangener Leerlauf-Niedrigleistungszustand-Residenz, um zukünftige Aktivität vorherzusagen.
• Bezugnehmend auf 4 ist eine Ausführungsform zum Vorhersagen zukünftiger Aktiv- und Leerlaufzustand-Residenz veranschaulicht. Bei einer Ausführungsform kann Prädiktor 435, der in Vorhersagemechanismus 315 beinhaltet ist, einen Kalman-Filteralgorithmus verwenden. Basierend auf Daten einer Aktiv-Residenz – manchmal als ein Arbeits- oder C0-Zustand bezeichnet – und Niedrigleistungs-Residenz – manchmal als Nicht-Arbeits- oder C2-CN-Zustand bezeichnet – von Kernen 301–30N wird eine Vorhersage berechnet. Es ist zu beachten, dass innerhalb der Erörterung spezifisch Bezug genommen wird auf spezifische Niedrigleistungszustände, wie z. B. C-Zustände, um die Erörterung zu fördern. Ein Einsetzen von Leerlauf- und/oder Aktiv-Residenz kann jedoch mit jeder Form von Leistungszuständen, Performanz-Zuständen, globalen Zuständen oder einer anderen Form von Aktivitäts- oder Nicht-Aktivitätsindikator verbunden sein.
• C-Zustände beziehen sich generell auf Leistungszustände wie von der Advanced Configuration and Power Interface (ACPI) definiert. Beispiele von Prozessor- oder Kerntypen, Leistungszustände gemäß der ACPI beinhalten: C0 ist eine arbeitende/aktive Art eines Zustands; C1 – oftmals bekannt als Halt – ist eine Art eines Zustands, bei dem der Prozessor keine Befehle ausführt, aber im Wesentlichen sofort in einen ausführenden Zustand zurückkehren kann; C2 – oftmals bekannt als Stopp-Clock – ist eine Art eines Zustands, bei dem der Prozessor alle für Software sichtbaren Zustände aufrechterhält, aber länger brauchen kann, um aufzuwachen; und C3 – oftmals bekannt als Sleep – ist eine Art eines Zustands, bei dem der Prozessor seinen Cache nicht kohärent halten muss, sondern einen anderen Zustand aufrechterhält. Einige Prozessoren weisen Varianten auf dem C3 – Deep Sleep (C4), Deeper Sleep (C5), Deepest Sleep (C6) – auf, die sich in der Dauer, um den Prozessor aufwachen zu lassen, und der Menge an Energieersparnis unterscheiden. Es ist zu beachten, dass einige der hierin beschriebenen Arten von C-Zuständen für einen beispielhaften Prozessor gelten, wie z. B. einen advanced Intel^® Architecture 32 (IA-32) Prozessor, erhältlich von der Intel Corporation, Santa Clara, CA; obwohl Ausführungsformen gleichermaßen mit anderen Prozessoren verwendet werden können. Hier können die C-Zustände für einen Intel^®-Prozessor sich nicht direkt mit den ACPI-Spezifikationen decken; dennoch sind für die Erörterung beide Sätze aktiver/inaktiver Zustande gleichermaßen geeignet. Mit anderen Worten können Prozessoren jegliche Anzahl ihrer eigenen angepassten C-Zustände der vorstehend beschriebenen ACPI-Art von C-Zuständen zuordnen.
• Wird die vorstehende Erörterung fortgeführt, dann kann Core-Hop-Manager 440, sobald Prädiktor 435 den Kalman-Filteralgorithmus einsetzt, um die Vorhersage basierend auf Daten von Aktivitätsmonitor 430 zu berechnen, eine Entscheidung treffen, ob ein Core-Hop basierend auf der Vorhersageentscheidung vermieden werden soll oder nicht. Demzufolge kann Aktivitätsmonitor 430 Daten überwachen, um die Aktiv- oder Leerlaufinformationen wie vorstehend erörtert zu bestimmen. Beispiele von Daten, die mit diesen Leistungszuständen verbunden sind, die von Monitor 430 überwacht werden können, beinhalten Leistungszustands-Eintritts-/Austrittsereignisse, wie z. B. Eintritts-/Austrittsereignisse für Kerne 301–30N während eines Überwachungszeitraumes oder -intervalls, sowie Berechnung von Residenz bei solchen Zuständen basierend auf den Eintritts-/Austrittsereignissen oder anderen Zählungen. Daraus wird ein Überlappen von aktiven Kernen/Kernen im Leerlauf in demselben Paket berechnet. Bei einer Ausführungsform kann das Intervall einer Aktivitätsüberwachung und -vorhersage alle 500 μs sein; dies kann jedoch leicht von einigen Ausführungszyklen zu tausenden Mikrosekunden reichen.
• Aktivitätsmonitor 430 wie vorstehend erwähnt kann somit eingehende Daten von den verschiedenen Kernen 301–30N hinsichtlich ihrer derzeitigen oder vergangenen Aktivitätslevel empfangen. Bei einer Ausführungsform beinhaltet Aktivitätsmonitor 430 einen Puffer, der auf verschiedene Arten angeordnet sein kann. Beispielsweise kann der Puffer angepasst sein, um für jeden Kern 301–30N eine Anzeige eines Zeitstempels zu speichern, der mit jedem Ereignis zum Ändern eines Leistungszustands verbunden ist. Hier unterbricht somit Aktivitätsmonitor 430 die Ereignisse, bei denen CPU-Kerne 301–30N in Leistungszustände ein- und austreten und vergibt Zeitstempel für diese Ereignisse. Bei einer Ausführungsform wird die Aufzeichnung in einem Kernel-Puffer gespeichert. Dann stellt Aktivitätsmonitor 430 bei vorab bestimmten Intervallen, wie z. B. dem vorstehend beschriebenen Intervall, überwachte Daten an Prädiktor 435 bereit. Diese überwachten Daten können somit Zeitstempeldaten sowie den Aktivitätszustand beinhalten, um während des Speicherintervalls anzuzeigen, wie lange jeder Kern sich in einem gegebenen Zustand befand.
• In Antwort darauf kann Prädiktor 435 diese Informationen verwenden, um eine Musterverteilung für vorhergesagte Kernzustände für das nächste Intervall zu generieren. Obwohl er in dieser Hinsicht nicht eingeschränkt ist, kann Prädiktor 435 bei einer Ausführungsform einen gegebenen Vorhersagealgorithmus, wie z. B. einen Kalman-Filteralgorithmus, ausführen, um diese Musterverteilung zu generieren. Des Weiteren ist es selbstverständlich, dass die Musterverteilung stark variieren kann, abhängig von einer Anzahl an unterstützten Niedrigleistungszuständen, sowie einer gegebenen Anzahl an Kernen, Länge des Vorhersagezeitraumes und so weiter. Um die Erörterung zu erleichtern, wird hierin eine Musterverteilung einschließlich dreier unterschiedlicher Muster beschrieben, wie z. B. die drei Gesamtmuster, die mit Bezug auf 5 ausführlicher erörtert werden. Es ist jedoch selbstverständlich, dass der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist, und bei unterschiedlichen Ausführungsformen können mehr oder weniger solcher Muster bereitgestellt werden, wie z. B. mit variierenden Körnungen hinsichtlich einer Anzahl an Kernen bei einem gegebenen Aktivitätslevel.
• Diese Musterverteilungsinformationen werden somit von Prädiktor 435 an Core-Hop-Manager 440 bereitgestellt, was basierend auf der Musterverteilung eine Core-Hop-Anfrage erlauben oder verweigern kann. Als Beispiel kann ein spezifisches Leerlauf-Aktivitäts-Gesamtmuster für ein nächstes Intervall anzeigen, dass ein Core-Hop effizient wäre. Hier erlaubt Core-Hop-Manager 440 den Core-Hop in Antwort auf die Gesamtmusterverteilung und/oder Residenz, die über einer Grenzwert-Residenz liegt. Mit anderen Worten wird der Core-Hop erlaubt, wenn Kerne 301–30N laut Vorhersage ein Aktiv-Leerlauf-Muster aufweisen, das lange genug verweilt, dass ein Core-Hop als machbar und effizient erachtet würde. Im Gegensatz dazu verweigert Core-Hop-Manager 440 die Core-Hop-Anfrage oder lehnt sie ab, wenn andere Leerlauf-Aktivitätsmuster, die nicht effizient oder nicht machbar sind, laut Vorhersage anstatt des effizienten Musters verweilen, wie von der Residenz des effizienten Musters, die unter dem Grenzwert liegt, angezeigt. Demzufolge können bei diesem Beispiel unnötige, ineffiziente oder nicht machbare Core-Hops basierend auf zukünftiger Vorhersage einer Aktivität der Kerne 301–30N vermieden werden.
• Bei einer Ausführungsform können die folgenden drei Muster berechnet werden, um Aktivität vorherzusagen: (1) MusterA: Paket ist im Leerlauf (alle inneren Kerne sind im Leerlauf); (2) MusterB: Paket ist beschäftigt (alle inneren Kerne sind beschäftigt); und (3) MusterC: Paket ist teilweise im Leerlauf (verbleibende Fälle – zumindest ein Kern ist beschäftigt und zur gleichen Zeit ist zumindest ein Kern im Leerlauf). Dieses dritte Muster stellt ein Szenario dar, bei dem im Leerlauf/Beschäftigt überlappen. Aus dem vorstehendem Beispiel ist ersichtlich, dass die Zeitstempel des Eintritts-/Austrittszustands von Kernen 301–30N von Aktivitätsmonitor 430 zur Verfügung gestellt werden. Und demzufolge können die drei Musterverteilungsvorhersagen berechnet werden. Eine beispielhafte Ausgabe einer Vorhersage gemäß einer Ausführungsform der vorliegenden Erfindung ist in Tabelle 1 gezeigt, wobei von einem Intervallzeitraum von 500 μs ausgegangen wird. Tabelle 1

  %MusterA im nächsten T1	25% (25%·500 = 125 μs Paket in MusterA)
  %MusterB im nächsten T1	15% (15%·500 = 75 μs Paket in MusterB)
  %MusterC im nächsten T1	60% (60%·500 = 300 μs Paket in MusterC)

• Somit wird, wie in Tabelle 1 für einen Intervallzeitraum T1 gezeigt, ein Paketmuster im Leerlauf für 25% der Zeit (d. h. 1 25 μs) vorhergesagt, während alle Kerne laut Vorhersage für 15% der Zeit (d. h. 75 μs) aktiv sind, und während der verbleibenden 60% des nächsten Vorhersagezeitraumes ist zumindest ein Kern aktiv und zumindest ein Kern im Leerlauf (d. h. 300 μs). Die Art und Weise des Generierens dieser Mustervorhersagen kann bei unterschiedlichen Ausführungsformen variieren. Bei einer Ausführungsform können die Vorhersagen ein Kalman-Filter verwenden, wie unmittelbar nachstehend weiter erörtert wird; andere Implementierungen sind jedoch möglich.
• Ein Kalman-Filter-Modell (Kalman filter model, KFM) modelliert einen teilweise beobachteten stochastischen Prozess mit linearer Dynamik und linearen Beobachtungen, die beide Gaußschem Rauschen unterliegen. Es ist ein effizientes rekursives Filter, das den Zustand eines dynamischen Systems aus einer Serie unvollständiger Messungen und Rausch-Messungen schätzt. Basierend auf einem KFM kann eine Aktivität von Kernen 301–30N bei einer Anzahl vorab bestimmter Muster angeführt werden (z. B. Prozentsatz/Residenz von Muster A, B und C, sowie anderer Muster, wie z. B. diejenigen, die nachstehend mit Bezug auf 5 beschrieben sind), die als die Beobachtungen eines stochastischen Prozesses reeller Zahlen erachtet werden, der in der Zeit-Domain diskretisiert ist, die durch y_1:t = (y₁ ... y_t) bezeichnet sind. Der verborgene Zustand des Prozesses, x_1:t = (x₁ ... x_t), wird ebenfalls als ein Vektor reeller Zahlen dargestellt. Die lineare stochastische Differenzengleichung bei KFM lautet: x(t) = Ax(t – 1) + w(t – 1) p(w) ~ N(0, Q) x(0) ~ N(x_1|0, V_1|0) [EQ. 1]
• Und die Mess-Gleichung lautet: y(t) = Cx(t) + V(t) p(v) ~ N(0, R) [EQ. 2]
• Die n×n-Übergangsmatrix A bei der Differenzengleichung 1 setzt den Zustand beim vorherigen t – 1 Zeitschritt in Bezug zu dem Zustand bei dem derzeitigen Schritt t, in Abwesenheit entweder einer Antriebsfunktion oder Prozessrauschens. Hier ist n die Anzahl verborgener Zustände. Bei unserem Task ist m = n die Anzahl möglicher CPU-Aktivitätszustände. x_1|0, V_1|0 sind der anfängliche Mittelwert und die Varianz des Zustands, Q ist die System-Kovarianz für das Übergangs-Dynamik-Rauschen und R ist die Beobachtungs-Kovarianz für das Beobachtungs-Rauschen. Der Übergang von Beobachtungsfunktionen ist für die gesamte Zeit derselbe und das Modell soll zeitinvariant oder homogen sein.
• Unter Verwendung des KFM können Werte auf der zukünftigen Zeit vorhergesagt werden, wobei alle Beobachtungen der derzeitigen Zeit ausgeliefert werden. Wir sind jedoch generell unsicher was die Zukunft angeht, und somit werden eine beste Schätzung sowie eine statistische Sicherheit berechnet. Somit wird eine Wahrscheinlichkeitsverteilung über die möglichen zukünftigen Beobachtungen berechnet, bezeichnet durch P(Y_t+h = y|y_1t), wobei k > 0 der Horizont ist, d. h. wie weit die Vorhersage in die Zukunft reicht.
• Angesichts der Sequenz vorherzusagender beobachteter Werte (y₁ – y_t), soll der neue Beobachtungswert P(Y_t+h = y|y_1:t) für irgendeinen Horizont k > 0 in der Zukunft berechnen. Gleichung 3 ist die Berechnung einer Vorhersage über die zukünftigen Beobachtungen, indem die Vorhersage des zukünftigen verborgenen Zustands ausmarginalisiert wird.
• 
• Im rechten Teil der Gleichung wird P(X_t+n = x|y_1:t) durch den Algorithmus der festen Zeitverzögerungs-Glättung berechnet, d. h. P(X_t-L = x|y_1:t), L > 0, L ist die Zeitverzögerung. Bevor also auf die Details des Algorithmus näher eingegangen wird, wird zuerst eine feste Zeitverzögerungs-Glättung im KFM eingeführt.
• Ein fester Zeitverzögerungs-Kalman-Glätter (fixed-lag Kalman smoother, FLKS) ist ein Ansatz, um rückwirkende Datenassimilation durchzuführen. Er schätzt den Zustand der Vergangenheit, wobei alle Beweise der derzeitigen Zeit ausgeliefert werden, d. h. P(X_t-L = x|y_1:t), L > 0, wobei L die Zeitverzögerung ist, z. B. will man herausfinden, ob ein Rohr vor L Minuten angesichts der derzeitigen Sensormesswerte brach. Dies wird traditionell „feste Zeitverzögerungs-Glättung” genannt, obwohl der Begriff „Rückschau” eventuell besser geeignet wäre. Im Offline-Fall wird dies (feste Intervall-)Glättung genannt; dies entspricht einer Berechnung von P(X_T-L = x|y_1:T), T ≥ L ≥ 1.
• Bei dem Vorhersagealgorithmus gibt es um h mehr Vorwärts- und Rückwärts-Durchgänge. Die Berechnung der Durchgänge ist ähnlich derjenigen bei dem Glättungsprozess. Der einzige Unterschied ist, dass bei dem Vorhersageschritt der anfängliche Wert der neuen Beobachtung Null beträgt, was bedeutet, dass y_1:T+h = [y_1:T y¹ _null --- y^h _null]. Der Vorhersagealgorithmus schätzt den Wert des y_1:T+h = y_1:Ty_T+1 --y_T+h], indem rückwirkende Datenassimilation auf allen Beweisen bis zur derzeitigen Zeit plus dem y_1:T+h = [y_1:Ty¹ _null --- y^h _null] durchgeführt wird. In der Praxis wird in Betracht gezogen, die vorherigen Schritte als die früheren Daten zu verwenden, beispielsweise wenn h = 1, dann y_T+1 = (y_T-1 ... y_T)/2 anstatt y_T+1 = null.
• Tabelle 2 zeigt den Pseudocode des Vorhersagealgorithmus.
• Tabelle 2

  
• Bei Tabelle 2 sind Fwd und Back die abstrakten Operatoren. Für jede Fwd(Vorwärts-Durchgang, forwards pass)-Operation der ersten Schleife (for t = 1:T) wird zuerst der Interferenz-Mittelwert und die Varianz mittels x_t|t-1 = Ax_t-1|t-1 und V_t|t-1 = AV_t-1|t-1A' + Q berechnet; dann werden der Fehler bei der Interferenz (die Innovation), die Varianz des Fehlers, die Kalman-Verstärkungsmatrix und die bedingte log-Wahrscheinlichkeit dieser Beobachtung mittels err_t = y_t – Cx_t|t-1, S_t = CV_t|t-1C' + R, K_t = V_t|t-1C'S_t ^–1 bzw. L_t = log(N(err_t; 0, S_t) berechnet; schließlich werden die Schätzungen des Mittelwertes und der Varianz mittels x_t|t = X_t|t-1 + K_terr_t und V_t|t = V_t|t-1 – K_tS_tK_t' aktualisiert.
• Für jede Back-(Rückwärts-Durchgang, backwards pass)-Operation der zweiten Schleife (for t = T – 1:–1:1) werden zuerst die Interferenzmengen mittels x_t+1|t = Ax_t|t und V_t+1|t = AV_t|tA' + Q berechnet und dann wird die Glätter-Verstärkungsmatrix mittels J_t = V_t|tA'V^–1 _t+1|t berechnet; schließlich werden die Schätzungen des Mittelwertes, der Varianz und Kreuzvarianz mittels x_t|T = x_t|t + J_t(x_t+1|T – x_t+1|t), V_t|T = V_t|t + J_t(V_t+1|T – V_t+1|t)J_t' bzw. V_t-1,t|T = J_t-1V_t|T berechnet, die als die Rauch-Tung-Striebel (RTS) Gleichungen bekannt sind.
• Die Berechnung wie in Tabelle 2 angeführt kann kompliziert sein, z. B. gibt es Matrixinversionen in der T + 1-Schritt-Schleife, wenn Kalman-Verstärkungsmatrix in Fwd-Operator und die Glätter-Verstärkungsmatrix in Back-Operator berechnet werden. Und die Berechnungskomplexität beträgt O(TN³), wobei T die Anzahl historischer Beobachtungen ist; N ist die Anzahl an Aktivitätszuständen, da für eine allgemeine N·N-Matrix ein Gaußsches Eliminationsverfahren zum Lösen der Matrixinverse zu O(N³)-Komplexität führt. Bei verschiedenen Ausführungsformen kann die Implementierung des Algorithmus jedoch vereinfacht sein. Eine spezifischere Erörterung zum Einsatz eines KFM, um zukünftige Aktivität zur Auswahl eines Leistungszustands vorherzusagen, ist in einer ebenfalls anhängigen Anmeldung mit dem Titel „Energiesparen in einem Computersystem” mit Anmeldenummer 11/955,326 beschrieben.
• Indem nun Bezug genommen wird auf 5, ist eine Ausführungsform potentieller Aktivitätsmuster, die ebenfalls als Leerlauf-Aktivitätsmuster bezeichnet werden können, vorhergesagter Aktivität, zukünftiger Aktivität, Aktivität des nächsten Intervalls, Aktivitäts-Darstellung, Leerlauf-Aktivitäts-Darstellung etc. veranschaulicht. Hier ist Prädiktor 435 als drei Leerlauf-Aktivitäts-Gesamtmuster 501, 502 und 503 vorhersagend dargestellt. Bei dieser Veranschaulichung stellt eine logische Eins dar, dass ein Kern aktiv ist – in einem Arbeits- oder C0-Zustand – und eine logische Null stellt dar, dass der Kern im Leerlauf ist – in einem Nicht-Arbeits- oder Nicht-C0-Leistungszustand. Jegliche Gruppierung von Leistungszuständen kann jedoch innerhalb der Definition von „aktiv” und „im Leerlauf” beinhaltet sein, wie z. B. dass C0 und C1 als aktiv angesehen werden und C2-C6 als im Leerlauf/inaktiv angesehen werden. Folglich entsprechen bei dem dargestellten Beispiel möglicher Aktivitätsmuster 505 Felder 505a–d je einer Aktivität von Kernen 301–304. Hier kann jedes Feld eine vorhergesagte Aktivität oder Inaktivität während eines nächsten oder zukünftigen Intervalls darstellen, was zu sechzehn möglichen Leerlauf-Aktivitätsmustern für vier Kerne führt. Durch Extrapolieren aus diesen einfachen Beispielen ergeben sich potentiell 2^N Muster für N Kerne.
• Ein Vorhersagemechanismus einschließlich Prädiktor 435 kann jegliche Form von Residenz für alle der möglichen 2^N Muster für ein zukünftiges/nächstes Intervall vorhersagen und diese dann in Gesamtmuster wie veranschaulicht zusammenfassen. Jegliche Untermenge der 2^N Muster kann jedoch als Gesamtmuster vorhergesagt werden.
• Zusätzlich kann ebenfalls Residenz eines jeden von möglichen Muster vorhergesagt werden, auch wenn Gesamtmuster vorhergesagt werden. Des Weiteren kann die Zusammenfassung von Muster auf jegliche Art und Weise durchgeführt werden, sodass sich die Gruppierungen von der Veranschaulichung von 5 unterscheiden können. Außerdem kann eine Residenz eines Musters in jeglicher Form ausgedrückt werden, wie z. B. einer Verteilung von Residenz, einem Prozentsatz von Residenz in einem Intervall, einer zeitlichen Menge an Residenz in einem nächsten Intervall oder einem anderen Ausdruck einer Zeit oder Menge die ein Muster laut Vorhersage in einem zukünftigen Intervall auftreten soll.
• Hier sind die vorhergesagten Muster von Aktivität für Kerne 301–304 in drei Gruppen zusammengefasst: 501, 502, 503. Obwohl nicht dargestellt, ist der einfachste Weg zum Bestimmen, ob ein Core-Hop effizient ist – erlaubt werden soll – Muster in zwei Gruppen zusammenzufassen: für Core-Hopping effiziente Aktivitätsmuster und für Core-Hopping ineffiziente Aktivitätsmuster. Im Wesentlichen beinhaltet Gesamtmuster 502, wie gezeigt, bei diesem Beispiel zusammengefasste Muster, die für Core-Hopping „effizient” sein sollen, während Muster 503 und 501 Muster beinhalten, die „ineffizient” sein sollen. Dieses Beispiel unterscheidet jedoch bei Ineffizienz. Muster 501 beinhaltet Muster, bei denen Core-Hopping machbar ist – leicht durchgeführt werden kann – aber es besteht kein Bedarf an Core-Hopping. Insbesondere die Verstärkung für eine thermische Dichte-Bedingung, die mit den in Muster 501 zusammengefassten Muster verbunden ist, wie z. B. 0000 oder 0101, wird als nicht vorteilhaft angesehen, wenn sie gegen eine zeitliche Benachteiligung – Zeit, um Core-Hop durchzuführen, die eine Ausführung blockiert – gewichtet wird.
• Es wird beispielsweise davon ausgegangen, dass Kerne 301–304 in einer Ring-Topologie verweilen, sodass Kern 301 sich entsprechend neben Kernen 302 und 304 befindet. Wenn hier ein Core-Hop für Kern 304 angefragt wird, wenn die derzeitige Aktivität 0101 beinhaltet, kann ein Hop des Kontextes von Kern 304 zu Kern 303 vorübergehend ein Wärmeproblem auf Kern 304 lindern. Insgesamt betrachtet kann sich das Wärmeproblem jedoch verschlechtern, da das Aktivitätsmuster nun 0110 ist, bei dem die Kerne 302 und 303 sich nebeneinander befinden anstatt in 0101 verteilt zu sein. Es kann sich nicht nur die gesamte thermische Bedingung des Prozessorpakets in diesem Fall verschlechtern, sondern die Wärmebedingung auf einer Pro-Kern-Basis kann einfach auf Kern 303 übertragen werden. Dennoch können bei einigen Implementierungen Designer dieses Muster als effizient erachten und es entsprechend mit anderen effizienten Muster zusammenfassen.
• Andererseits beinhaltet Muster 503 Muster, die von einem Core-Hop profitieren können. Aber ein Core-Hop ist potentiell ineffizient, da er nicht machbar ist oder eine wesentliche thermische Bedingungserleichterung im Vergleich mit der zeitlichen Ausführungsbenachteiligung, die durch einen Core-Hop anfällt, fehlt. Beispielsweise zeigt ein Muster 1111 an, dass Kerne 301–304 alle beschäftigt sind. Daher ist ein Hop von einem Kern zu einem anderen lediglich ein Umschalten von einem aktiven Kern zu einem anderen. Zusätzlich können Muster, wie z. B. 1011, innerhalb dieser Untermengen-Gruppe beinhaltet sein, da ein Umschalten/Hoppen von Kontext von Kern 301 zu Kern 302, um das Muster 0111 zu erhalten, die initiierende thermische Bedingung wie vorstehend beschrieben noch verschlechtern kann.
• Es ist zu beachten, dass diese Gruppierungen, Zusammenfassungen oder Untermengen der möglichen 2^N Muster nicht auf Gruppierungen beschränkt sind, die auf einem Gewichten potentieller thermischer Bedingungserleichterung gegen zeitliche Benachteiligung für Ausführung oder zeitlichen Benachteiligungen basiert. In der Tat kann in einigen Fällen eine Core-Hopping-Richtlinie rein auf Machbarkeit hin gruppieren. Bei dieser Ausführungsform wird, wenn ein Core-Hop machbar ist, dieser als effizient bestimmt, während nicht machbare Core-Hops als ineffizient bestimmt werden. Daher kann ein Vorhersagemechanismus jegliche Richtlinie implementieren, um Leerlauf-Aktivitätsmuster in Gesamtmuster zu gruppieren. Des Weiteren kann eine Zusammenfassung jegliche Gruppierung oder Verbindung von Muster beinhalten. Bei einer Ausführungsform beinhaltet eine Zusammenfassung ein Zusammenfassen von Residenzen von Muster. Es wird beispielsweise davon ausgegangen, dass eine Residenz, wie z. B. die Residenz von Gesamtmuster 502, als ein Prozentsatz eines Intervalls ausgedrückt ist, wie z. B. 70%, was leicht in eine Menge an Zeit für ein Intervall (70%·0500 μs = 350 μs) umgewandelt werden kann. Dies zeigt im Wesentlichen an, dass Prädiktor 435 vorhersagt, dass während des zukünftigen 500 μs-Intervalls irgendeine Version der Muster, die Gesamtmuster 502 ausmachen, 350 μs oder 70% des Intervalls verweilen wird.
• Um das Beispiel zu fördern, wird davon ausgegangen, dass Prädiktor 435 vorhergesagt hat, dass Muster 1100 10% des nächsten Intervalls verweilen soll, Muster 0011 30% des nächsten Intervalls verweilen soll und Muster 1001 10% des nächsten Intervalls verweilen soll. Bei diesem Beispiel beinhaltet eine Zusammenfassung einfach die Summe der individuellen Muster – 10% + 20% + 30 + 10% – um die Gesamtresidenz von 70% zu erhalten. Wie vorstehend aufgeführt, kann eine Zusammenfassung jedoch jegliche Gruppierung von Muster oder Residenzen dafür beinhalten. Es ist zu beachten, dass die tatsächliche Residenz individueller Muster und Gesamtmuster im Vergleich zu den vorhergesagten Residenzen variieren kann. Während einer Simulation wurde jedoch herausgefunden, dass Prädiktoren, wie z. B. Prädiktor 435, sehr genau sein können. In der Tat zeigte ein Satz an Simulationen an, dass ein Prädiktor auf einem Vierkernprozessor lediglich einen relativen Fehler von 4,34% aufwies. Mit anderen Worten, wenn der Prädiktor eine Residenz eines Musters, wie z. B. 0101, von 300 μs für ein 500 μs-Intervall vorhersagt, dann ergab das tatsächliche, gemessene Ergebnis, dass das Muster zwischen 287 μs und 313 μs verweilte.
• Bei einer Ausführungsform soll während eines Intervalls Core-Hopping-Mechanismus 320 oder Core-Hop-Manager 440 basierend auf der zukünftigen/vorhergesagten Aktivität der Vielzahl an Prozessorkernen für das Intervall bestimmen, ob Core-Hopping effizient ist. Es ist zu beachten, dass ein Teil oder diese gesamte Bestimmung in Vorhersagemechanismus 315 sowie potentiell in anderer Logik gemacht werden kann. Wird das vorstehende Beispiel fortgeführt, bestimmt Core-Hop-Manager 440, ob ein Core-Hop effizient ist, sobald Prädiktor 435 die Residenzen für Gesamtmuster 501, 502 und 503 vorhergesagt hat. Bei einer Ausführungsform beinhaltet ein Bestimmen, dass ein Core-Hop effizient ist, dass bestimmt wird, ob die Gesamtgruppe effizienter Core-Hop-Muster laut Vorhersage lange genug in dem nächsten Intervall verweilt, um Core-Hopping effizient zu erachten.
• Beispielsweise wird bestimmt, ob die Residenz von Gesamtmuster 502 effizienter Core-Hop-Muster über einem Grenzwert liegt, wie z. B. einem Residenz-Grenzwert. Es ist zu beachten, dass der Grenzwert jeglichen Prozentsatz, Zeit, Verteilung oder anderen Wert beinhalten kann, der dem Ausdruck von Musterresidenz entspricht. Zur Veranschaulichung wird davon ausgegangen, dass der Grenzwert 60% beträgt. Bei dem vorstehenden Beispiel, bei dem die Residenz von Gesamtmuster 502 70% beinhaltet, übersteigt das vorhergesagte effiziente Leerlauf-Aktivitätsmuster den Grenzwert – laut Vorhersage verweilt es länger als der Grenzwert. Hier erlaubt Core-Hop-Manager 440 den Core-Hop, da er als effizient bestimmt wurde. Wenn der Grenzwert jedoch 75% betragen würde, dann würde Core-Hop-Manager 440 den Core-Hop ablehnen, da das effiziente Muster laut Vorhersage nicht lange genug in dem Intervall verweilt. Es ist zu beachten, dass bei einigen Ausführungsformen der Residenz-Grenzwert vorab bestimmt sein kann, während er bei anderen Ausführungsformen durch Entitäten auf privilegiertem Level, Entitäten auf nicht privilegiertem Level oder eine Kombination davon dynamisch eingestellt werden kann.
• Bei einer Ausführungsform kann Core-Hop-Manager 440 ebenfalls eine optimale Konfiguration für Core-Hops basierend auf der Core-Hop-Anfrage bestimmen. Beispielsweise kann ein Core-Hop-Manager in Antwort auf ein Empfangen einer Hop-Anfrage von Kern 304 Aktivitätsmonitor 430 befragen, um ein derzeitiges Aktiv-Leerlauf-Muster zu bestimmen oder die Vorhersage einer Residenz eines Musters in dem Intervall einsetzen, um einen Hop zur optimalen Konfiguration auszuwählen. Hier wird davon ausgegangen, dass ein einzelnes Muster 0011 laut Vorhersage die längste Residenz während des nächsten Intervalls aufweist. Dann kann ein Core-Manager in Antwort auf die Core-Hop-Anfrage bestimmen, dass der Kontext von 304 zu Kern 301, nicht 302, gehoppt werden soll, da in dem am längsten verweilenden Muster – 0011 – während des nächsten Intervalls Kerne 302 und 303, die sich nebeneinander befinden, zur gleichen Zeit aktiv wären. Eine Bestimmung einer optimalen Konfiguration ist nicht darauf beschränkt, dass sie auf einem einzelnen Muster basiert. Stattdessen kann eine Kombination oder Zusammenfassung verwendet werden. Beispielsweise können vorhergesagte Muster, die anzeigen, dass spezifische Kerne aktiv sind, kombiniert werden, und die Residenz der Kombination kann geschätzt werden, um einen optimalen Core-Hop zu bestimmen.
• Es ist ebenfalls zu beachten, dass die Bestimmung des Core-Hop-Mechanismus 320 nicht auf Aktivitätsmustern gemacht werden kann, sondern vielmehr bei einigen Ausführungsformen auf jeglicher Vorhersage einer zukünftigen Aktivität gemacht werden kann, die eingesetzt werden kann, um anzuzeigen, ob ein Core-Hop effizient ist. In der Tat sind zahlreiche Beispiele vor der Erörterung von 4 zur Vorhersage einer zukünftigen Aktivität vorstehend beschrieben. Daher kann jegliches bekannte Verfahren oder jegliche bekannte Vorrichtung zum Bestimmen, ob ein Core-Hop effizient wäre, eingesetzt werden. Des Weiteren ist es nochmals wichtig zu beachten, dass die Untermengen-Gruppierungen der dargestellten Gesamtmuster sowohl bei Anzahl als auch Inhalt rein veranschaulichend sind.
• Wendet man die Erörterung 6 zu, ist eine Ausführungsform eines Verfahrens dargestellt, um ineffizientes Core-Hopping zu vermeiden. Obwohl die Abläufe von 6 und 9a nachstehend auf eine im Wesentlichen serielle Weise veranschaulicht sind, kann jeder der Abläufe zumindest teilweise parallel oder in einer anderen Reihenfolge durchgeführt werden. Des Weiteren können einige der veranschaulichten Abläufe weggelassen werden, während andere Abläufe bei unterschiedlichen Ausführungsformen beinhaltet sein können. Beispielsweise kann eine Residenz am Ende eines vorherigen Intervalls für ein nächstes oder zukünftiges Intervall vorhergesagt werden. Während der Simulationen betrug eine Vorhersage im Schnitt ungefähr 6,5 Mikrosekunden. Daher kann ein Intervall enden, eine Vorhersage kann beginnen und eine Core-Hop-Anfrage kann teilweise parallel stattfinden. Demzufolge ist die Reihenfolge von sowohl in 6 als auch 9a gezeigten Abläufen rein veranschaulichend.
• Bei Ablauf 605 wird eine Residenz einer Leerlauf-Aktivitäts-Darstellung für eine Vielzahl an Kernen auf einem Prozessor während eines zukünftigen Intervalls vorhergesagt. Wie vorstehend ausgeführt kann die Leerlauf-Aktivitäts-Darstellung jegliche bekannte Darstellung einer Aktivität eines Verarbeitungselements beinhalten. Bei einem Beispiel beinhaltet die Leerlauf-Aktivitäts-Darstellung ein erstes Leerlauf-Aktivitäts-Gesamtmuster einer Anzahl effizienter Leerlauf-Aktivitätsmuster. Hier kann Aktivität von N Kernen dargestellt sein durch 2^N Muster, wobei durch eine Plattform-Richtlinie bestimmt wird, dass die effizienten Leerlauf-Aktivitätsmuster effizient sind, wie z. B. Gewichten einer Verstärkung von Core-Hopping, um eine thermische Dichte-Bedingung zu erleichtern, und zeitliche Ausführungskosten zum Durchführen des Core-Hops. Ein spezifisches veranschaulichendes Beispiel solch eines effizienten Leerlauf-Aktivitätsmusters ist als Gesamtmuster 502 in 2 dargestellt. Es ist zu beachten, dass, wie in 2 gezeigt, mehr als ein Gesamtmuster vorhergesagt und berechnet werden kann. In der Tat kann Residenz aller der möglichen 2^N Muster bei einer Ausführungsform vorhergesagt und zusammengefasst werden, während lediglich Untermengen der 2^N Muster und der Gesamtmuster bei anderen Ausführungsformen vorhergesagt und berechnet werden können.
• Während des Intervalls wird eine Core-Hop-Anfrage empfangen. Es ist zu beachten, dass Core-Hop-Anfragen und ihre Generierung hierin nicht im Detail erörtert sind, um zu vermeiden, dass die Erörterung darüber, ob die Core-Hop-Anfrage vermieden werden soll oder nicht, in den Hintergrund rückt. Eine Core-Hop-Anfrage kann jedoch basierend auf jeglichen bekannten Bedingungen, wie z. B. einer thermischen Dichte-Bedingung, einer Auslastungs-Bedingung, einer Fehler-Bedingung etc., generiert werden.
• Zusätzlich kann jegliche Entität die Core-Hop-Anfrage generieren. Beispielsweise kann die Core-Hop-Anfrage durch Hardware ausgelöst werden, wie z. B. Core-Hop-Auslöselogik 310 in 3. Die Core-Hop-Anfrage kann ebenfalls durch eine Software-Entität auf privilegiertem Level, wie z. B. einem Kernel oder OS, generiert werden. In der Tat können sich einige Prozessordesigner dazu entscheiden, den Anfragemechanismus Code auf Benutzerebene zu öffnen, sodass Core-Hop-Auslöselogik 310 eine Benutzeranfrage empfängt und die Core-Hop-Anfrage generiert.
• Bei Entscheidungsablauf 615 wird bestimmt, ob eine vorhergesagte Residenz für die effiziente Leerlauf-Aktivitäts-Darstellung über einem Grenzwert liegt. Beispielsweise wird bestimmt, ob die Residenz von Gesamtmuster 502 über einem Residenz-Grenzwert liegt. Es ist zu beachten, dass die Alternative zu dieser Bestimmung, um zu demselben Ziel zu kommen, ein Durchführen der Vorhersage einer Residenz für eine Zusammenfassung ineffizienter Muster, wie z. B. Muster 501 und 503, beinhaltet. Und dann zu bestimmen, ob diese Zusammenfassung unter dem Grenzwert liegt. Im Wesentlichen bestimmt das letzte Beispiel anstatt zu bestimmen, ob effiziente Core-Hop-Muster lange genug verweilen werden, dass ein Core-Hop effizient wäre, ob ineffiziente Core-Hop-Muster nicht lange genug verweilen werden, dass ein Core-Hop effizient wäre.
• In Antwort auf die Bestimmung, die irgendeine Art Vergleich der vorhergesagten Residenz mit dem Residenz-Grenzwert beinhalten kann, wird die Anfrage entweder bei Ablauf 625 erlaubt, wenn die vorhergesagte Residenz über dem Grenzwert liegt – der Core-Hop ist effizient – oder bei Ablauf 620 abgelehnt/vermieden, wenn die vorhergesagte Residenz den Grenzwert nicht übersteigt – der Core-Hop ist ineffizient. Einen Core-Hop zu erlauben kann einfach beinhalten, dass man normale Core-Hop-Logik, wie z. B. Logik zum Migrieren eines Zustands von einem Kern zu einem anderen, ihre Aufgabe durchführen lässt, während ihn abzulehnen jede Form von Blockieren, Verweigern, Ablehnen oder eine andere Operation beinhaltet, um ein Stattfinden des Core-Hops zu stoppen.
• Ausführungsformen von Hardware-unterstützter Auswahl eines Niedrigleistungszustands
• Wendet man sich als nächstes 7 zu, ist eine Ausführungsform eines Prozessors einschließlich eines Leistungsmechanismus dargestellt, um zwischen einem angefragten Leistungszustand und einem vorhergesagten Leistungszustand basierend auf Vorhersagegenauigkeit auszuwählen. Wie veranschaulicht empfängt Leistungsmechanismus 710 eine Anfrage für einen Kern, wie z. B. Kern 701 von Kernen 701–704, um in einen angefragten Leistungszustand einzutreten. Aus der vorstehenden Erörterung ist zu beachten, dass der angefragte Leistungszustand jeglichen Leistungszustand, wie z. B. einen C-Zustand, ACPI-Leistungszustand, oder anderen bekannten Leistungszustand beinhalten kann. Zuvor wurde der angefragte Leistungszustand von einer Leistungssteuereinheit eingesetzt, die rein auf Software-Anfrage 741 basiert. Demzufolge fragt eine Software-Entität 740, wie z. B. ein Betriebssystem (Operating System, OS), Kernel, Hypervisor oder Virtual Machine Monitor (VMM), einen Leistungszustand für Kern 701 an, und es wird entsprechend in den Leistungszustand eingetreten. Ganz wie jedoch mit Core-Hopping vorstehend, können ohne Vorhersage einer Leerlaufdauer für Kern 701 von Kern 701 Kosten/Aufwand für ein Eintreten in einen Niedrigleistungszustand und anschließendes erneutes Aufwachen in kurzer Zeit anfallen. In der Tat kann Kern 701 in diesem Fall in den Niedrigleistungszustand eintreten und dort kürzer verweilen als Zeit benötigt wird, um Kern 701 aus diesem Leistungszustand aufwachen zu lassen. Als zusätzliche Komponente erörtert eine ebenfalls anhängige Anmeldung mit dem Titel „Energiesparen in einem Computersystem” mit Anmeldenummer 11/955,326, Hardware-Unterstützung/-Demotion von Leistungszuständen, wenn ein Kern länger in einem Leistungszustand verweilt. Es ist zu beachten, dass Hardware-Unterstützung und -Demotion in Verbindung mit den hierin beschriebenen Vorrichtungen und Verfahren eingesetzt werden kann. Beispielsweise kann Hardware eine vorhergesagte Leerlaufdauer oder einen vorhergesagten Leistungszustand vorhersagen, und Software kann einen angefragten Leistungszustand anfragen. Ist die Hardware genau, wird der vorhergesagte Leistungszustand ausgewählt. Verweilt der Kern jedoch zu lange oder nicht lange genug in dem vorhergesagten Leistungszustand, kann der Leistungszustand anschließend, wie in der ebenfalls anhängigen Anmeldung erörtert, zurückgestuft/unterstützt werden.
• Bei einer Ausführungsform soll Leistungsmechanismus 710 Hardware-unterstützte Auswahl eines Leistungszustands bereitstellen. In der Tat kann als potentielle Optimierung die Auswahl des Leistungszustands auf Vorhersagegenauigkeit basieren, sodass, wenn eine Hardware-Vorhersagegenauigkeit hoch ist, ein von Hardware vorhergesagter Leistungszustand ausgewählt wird. Und wenn eine Hardware-Vorhersagegenauigkeit gering ist, wird der von der Software angefragte Leistungszustand ausgewählt. Demzufolge hat die Auswahl der Hardware Priorität, wenn eine Hardware den richtigen – für ein zukünftiges Intervall effizientesten – Leistungszustand genau vorhersagt, während eine Hardware die Priorität einer Software abtritt, wenn der Vorhersagemechanismus nicht sehr genau ist. In der Tat wurde während Simulationen herausgefunden, dass eine Auswahl eines Leistungszustands durch Power-Management eines Betriebssystems zu 34,8% richtig ist; eine Ausführungsform reiner Hardware-Vorhersage war zu 92,7% richtig, und eine Ausführungsform eines Hybrids Hardware-unterstützter Auswahl eines Leistungszustands basierend auf der Hardware-Genauigkeit erzielte den richtigen Leistungszustand zu 94,3%.
• Bei einer Ausführungsform beinhaltet Leistungsmechanismus 710 Vorhersagemechanismus 720, um eine Leerlaufdauer oder einen vorhergesagten Leistungszustand vorherzusagen. Es ist zu beachten, dass ein Vorhersagemechanismus die Leerlaufdauer, wie z. B. eine sehr lange, lange, kurze oder sehr kurze Dauer, vorhersagen kann, und Leistungszustände sind damit durch Hardware, Firmware, Software oder einer Kombination davon verbunden. Zur Veranschaulichung können eine sehr lange und lange Dauer mit einem tiefsten Sleep-Zustand – C6 – verbunden sein, während die kurze und sehr kurze Dauer mit einem Sleep-Zustand – C3 – verbunden sind. Bei dieser Veranschaulichung ist die Verwendung der Begriffe Vorhersage eines Niedrigleistungszustands, wie z. B. C3 und C6, synonym mit einer Ausführung, dass eine Leerlaufdauer vorhergesagt wird oder umgekehrt.
• Bei einer Ausführungsform soll Vorhersagemechanismus 720 eine vorhergesagte Leerlaufdauer in Antwort auf eine gemessene Leerlaufdauer erhöhen oder senken. Während eines Intervalls beispielsweise bestimmt/misst ein Aktivitätsmonitor, wie z. B. Monitor 430 von 4, die Leerlaufdauer eines Kerns, wie z. B. Kern 701, unter Einsatz von Zählerlogik und/oder Zeitstempeln. Basierend auf dieser Leerlaufdauer wird entsprechend eine zukünftige/vorhergesagte Leerlaufdauer aktualisiert. Als veranschaulichendes Beispiel wird die vorhergesagte Leerlaufdauer in Antwort auf die gemessene Leerlaufdauer im Vergleich zu einem Break-Even-Grenzwert erhöht oder gesenkt. Wenn Leistung von Software-Entität 740 angefragt wird, dann beinhaltet der Break-Even-Grenzwert bei einer Ausführungsform eine Break-Even-Zeit eines tiefsten Leistungszustands, wie z. B. C6. Es ist zu beachten, dass eine Break-Even-Zeit von C6 vorab bestimmt sein kann. Die Break-Even-Zeit kann ebenfalls eine Menge an Zeit beinhalten, um von einem C6-Leistungszustand in einen aktiven Zustand aufzuwachen, sowie jegliche andere zeitliche Metrik, die mit einem Eintreten in einen/Austreten aus einem Leistungszustand verbunden ist.
• Wird das Beispiel fortgeführt, dann wird die vorhergesagte Leerlaufdauer durch Vorhersagemechanismus 720 erhöht, wenn die gemessene Leerlaufdauer während des vorherigen Intervalls länger war als die C6-Break-Even-Zeit. Alternativ wird dann die vorhergesagte Leerlaufdauer durch Vorhersagemechanismus 720 gesenkt, wenn die gemessene Leerlaufdauer während des vorherigen Intervalls kürzer war als die C6-Break-Even-Zeit. Es ist wichtig zu beachten, dass die Break-Even-Zeit eines Leistungszustands ein rein veranschaulichender Grenzwert ist. Und jegliche Menge an Zeit oder ein anderer Wert kann als ein Grenzwert eingesetzt werden, wenn diese(r) mit einer gemessenen/tatsächlichen Leerlaufdauer von einem Intervall verglichen wird. Wie vorstehend ausgeführt, kann die vorhergesagte Leerlaufdauer einem Leistungszustand entsprechen.
• Eine Aktualisierung einer vorhergesagten Leerlaufdauer stellt bei einigen Ausführungsformen jedoch nicht notwendigerweise eine Änderung des vorhergesagten Leistungszustands dar. Zur Veranschaulichung wurden bei dem vorstehenden Beispiel lange und sehr lange Leerlaufdauern mit C6 und kurze und sehr kurze mit C3 verbunden. Demzufolge stellt eine Erhöhung der vorhergesagten Leerlaufdauer von lang zu sehr lang noch immer einen vorhergesagten Leistungszustand C6 dar. Liegt die gemessene Leerlaufdauer jedoch unter dem Break-Even-Grenzwert, dann wird die vorhergesagte Leerlaufdauer von lang zu kurz gesenkt, was eine Änderung des vorhergesagten Leistungszustands von C6 zu C3 darstellt. In letzterem Fall wird davon ausgegangen, dass von Software-Entität 740 eine Anfrage für Kern 701 empfangen wurde, in einen Niedrigleistungszustand, wie z. B. C6, einzutreten. Vorhersagemechanismus 720 hat die Messung einer Leerlaufdauer für Kern 701 während eines Intervalls beendet. Hier liegt die gemessene Leerlaufdauer unter einer C6-Break-Even-Zeit, was den Vorhersagemechanismus 720 veranlasste, eine kurze Leerlaufdauer vorherzusagen. Wird davon ausgegangen, dass eine Hardware-Vorhersage zu diesem Zeitpunkt als genau erachtet wird, kann Power-Manager 715 den von der Hardware vorhergesagten Zustand C3 – basierend auf der von der Hardware vorhergesagten kurzen Leerlaufdauer – für Kern 701 über den von Software angefragten C6-Zustand auswählen.
• Bei noch einer Ausführungsform wird eine Auswahl eines von einer Hardware vorhergesagten Leistungszustands auf eine Vorhersagegenauigkeit des Hardware-Vorhersagemechanismus 720 hin festgelegt. Im Wesentlichen bei dieser Ausführungsform besteht eine Schutzmaßnahme, bei der von Hardware vorhergesagte Leistungszustände nicht mit Priorität über von Software angefragte Leistungszustände ausgewählt werden, wenn die Hardware keine genaue Vorhersage abgibt. Daher soll bei einer Ausführungsform Vorhersagegenauigkeitsmechanismus 725 eine Vorhersagegenauigkeit von Vorhersagemechanismus 720 vorhersagen. Als Beispiel soll Vorhersagegenauigkeitsmechanismus 725 eine Vorhersagegenauigkeit in Antwort auf die über das Intervall gemessene Leerlaufdauer, die den Break-Even-Grenzwert/-Dauer übersteigt, und die vorhergesagte Leerlaufdauer, die einer langen Leerlaufdauer entspricht, erhöhen. Mit anderen Worten war die Leerlaufvorhersage richtig, wenn die vorhergesagte Leerlaufdauer eine lange Leerlaufdauer ist – länger als eine Grenzwertdauer – und die tatsächliche, gemessene Leerlaufdauer ebenfalls über dem Break-Even-Grenzwert liegt. So erhöht Vorhersagegenauigkeitsmechanismus 725 die Genauigkeit basierend auf der bestimmten, genauen Vorhersage. Eine Vorhersage einer langen Leerlaufdauer und Messung einer ähnlichen langen Leerlaufdauer – die eine Break-Even-Dauer übersteigt – ist jedoch nicht die einzige Vorhersage, die als genau bestimmt werden kann. Als weiteres Beispiel erhöht eine Messung einer kurzen Leerlaufdauer – weniger als die Break-Even-Zeit – wenn eine kurze Leerlaufzeit vorhergesagt ist die Vorhersagegenauigkeit ebenfalls.
• Auf ähnliche Weise soll Vorhersagegenauigkeitsmechanismus 725 die Vorhersagegenauigkeit in Antwort auf die über das Intervall gemessene Leerlaufdauer, die die Break-Even-Dauer übersteigt, und die vorhergesagte Leerlaufdauer, die einer kurzen Leerlaufdauer entspricht, senken. Des Weiteren soll Vorhersagegenauigkeitsmechanismus 725 die Vorhersagegenauigkeit in Antwort auf die über das Intervall gemessene Leerlaufdauer, die die Break-Even-Dauer nicht übersteigt – eine gemessene kurze Leerlaufdauer – und die vorhergesagte Leerlaufdauer, die der langen Leerlaufdauer entspricht, senken.
• Es ist zu beachten, dass die vorstehenden Beispiele sich mit einer Vorhersage einer Leerlaufdauer befasst haben, und ein Bestimmen der Genauigkeit solcher Vorhersagen wird erörtert. Eine Vorhersage ist jedoch dahingehend nicht eingeschränkt. Als Beispiel kann eine Vorhersage eine Vorhersage tatsächlicher Leistungszustände oder Residenzen von Leistungszuständen innerhalb eines Intervalls beinhalten. Hier kann ein Aktivitätsmonitor Daten über einen Eintritt in/Austritt aus solchen Leistungszuständen sammeln. Und die Vorhersagen werden mit den Daten verglichen, um eine Genauigkeit direkter Vorhersage eines Leistungszustands zu bestimmen.
• Dennoch soll, trotz des Verfahrens des Vorhersagens, sobald die Hardware-Vorhersage getätigt wird, Power-Manager 715 den vorhergesagten Zustand für einen Kern, wie z. B. Kern 701, oder den angefragten Zustand für Kern 701 basierend auf der Vorhersagegenauigkeit von Leistungsmechanismus 720 auswählen. Bei einer Ausführungsform wird ein Genauigkeitsgrenzwert bereitgestellt. Wenn hier die Vorhersagegenauigkeit den Genauigkeitsgrenzwert übersteigt, dann wird der von der Hardware vorhergesagte Leistungszustand ausgewählt/eingesetzt. Wenn die Vorhersagegenauigkeit jedoch den Grenzwert nicht übersteigt, dann wird der angefragte Leistungszustand ausgewählt.
• Indem als nächstes auf 8 Bezug genommen wird, ist eine spezifische veranschaulichende Ausführungsform von Vorhersagelogik, um Leerlaufdauer/Leistungszustände vorherzusagen, und Genauigkeitslogik, um Vorhersagegenauigkeit zu bestimmen, dargestellt. In der Tat wird hier ein vereinfachtes, veranschaulichendes Beispiel erörtert, das beispielhafte Anzahlen und Zustände einsetzt, um einen Blick auf den Betrieb der Logik in 8 bereitzustellen. Vorhersagelogik 720 soll einen vorhergesagten Niedrigleistungszustand basierend zumindest auf einer Leerlaufdauer eines Kerns, wie z. B. Kern 701, der Vielzahl an Kernen über ein Intervall vorhersagen. Hier soll Leerlaufdauerlogik 805 die Leerlaufdauer des Kerns über das Intervall bestimmen. Als Beispiel kann das Intervall ein zeitlich festgelegtes Intervall sein, wie z. B. ein 500 μs-Intervall. Alternativ kann das Intervall die Leerlaufdauer selbst beinhalten. Bei dieser Ausführungsform soll Zähllogik, wie z. B. ein Zähler, die Leerlaufdauer für Kern 701 zählen, wenn ein Kern, wie z. B. Kern 701, in einen Niedrigleistungszustand – Leerlauf – eintritt. Es ist zu beachten, dass ein Aktivitätsmonitor, der Zeitstempel einsetzt, wie mit Bezug auf 4 erörtert, ebenfalls eingesetzt werden kann, um eine Leerlaufdauer zu bestimmen. Bei einem Aufwachen von Kern 701 aktualisiert Vorhersagelogik 720 ihre Vorhersage, und Vorhersagegenauigkeitslogik 725 aktualisiert entsprechend ihre Genauigkeit von Vorhersagelogik 720. In Antwort auf das Aufwachen stellt Leerlaufdauerlogik 805 die gemessene Leerlaufdauer 806 an Break-Even-Logik 810 bereit.
• Break-Even-Logik 810 soll bestimmen, ob die gemessene Leerlaufdauer 806 eine lange Dauer oder eine kurze Dauer ist. Wie vorstehend erörtert, wird bei einer Ausführungsform eine Break-Even-Zeit eines Leistungszustands, wie z. B. ein C6-Zustand, als ein Break-Even-Grenzwert eingesetzt. Obwohl jeglicher Break-Even-Wert eingesetzt werden kann, wird bei diesem Beispiel davon ausgegangen, dass der Break-Even-Grenzwert 100 μs beträgt. Wenn demzufolge Leerlaufdauer 806 100 μs übersteigt, dann wird die Leerlaufdauer von Kern 701 als eine lange Dauer bestimmt. Wenn umgekehrt Leerlaufdauer 806 bei oder unter 100 μs liegt, dann wird die Leerlaufdauer als eine kurze Dauer bestimmt. Als einfaches Beispiel kann Break-Even-Logik 810 Vergleichslogik beinhalten, um Leerlaufdauer 806 mit der Break-Even-Dauer von 100 μs zu vergleichen.
• Vorhersagezustandslogik 815, 820 sollen den vorhergesagten Niedrigleistungszustand basierend auf der Break-Even-Logik, d. h. lange oder kurze Leerlaufbestimmung von Break-Even-Logik 810, bestimmen. Element 820 für vorhergesagten Leerlauf/Leistungszustand soll einen vorherigen vorhergesagten Leistungszustand enthalten. Es ist zu beachten, dass jegliche Anzahl an Leistungszuständen und/oder Leerlaufdauer in Element 820 dargestellt werden kann. Als veranschaulichende Ausführungsform soll Speicherelement 820 eine Zwei-Bit Darstellung eines Leerlaufzustands enthalten, der Leistungszuständen entspricht. Hier stellt 00 eine sehr kurze Leerlaufdauer dar, die einem C3-Leistungszustand entspricht; 01 stellt eine kurze Leerlaufdauer dar, die ebenfalls dem C3-Leistungszustand entspricht; 10 stellt eine lange Leerlaufdauer dar, die einem C6-Leistungszustand entspricht; und 11 stellt eine sehr lange Leerlaufdauer dar, die ebenfalls dem C6-Leistungszustand entspricht. Wenn demzufolge ein angefragter Leistungszustand von Software-Entität 740 für Kern 701 empfangen wird, wird die vorhergesagte Leerlaufdauer/der Leistungszustand 822 Power-Manager 715 als der von der Hardware vorhergesagte Leistungszustand bereitgestellt.
• Wird dennoch das vorstehende Beispiel fortgeführt, kann der vorhergesagte Leerlauf-Leistungszustand 820 durch vorhergesagten Leerlaufzustandsmechanismus 815 basierend auf langen/kurzen Leerlaufdauerinformationen 811 aktualisiert werden. Indem kurz auf 9b Bezug genommen wird, ist eine Ausführungsform eines Ablaufdiagramms für vorhergesagte Leerlaufzustandsmaschine 815 veranschaulicht. Wie basierend auf der langen/kurzen Leerlaufbestimmung von Break-Even-Logik 810 ersichtlich, werden die Zustände von Zustandsmaschine 815 entsprechend aktualisiert. Wenn beispielsweise der vorherige, in Element 820 enthaltene Zustand eine 01 – vorhergesagte kurze Leerlaufdauer 816b – beinhaltet und eine lange Leerlaufdauer bestimmt wird, dann verschiebt die lange Leerlaufdauer die Zustandsmaschine zu Zustand 816c – einem vorhergesagten langen Leerlaufzustand. Dieses Ergebnis kann in Zustandsmaschine 815 enthalten sein und direkt an Power-Manager 715 bereitgestellt werden. Oder das Ergebnis wird, wie veranschaulicht, in Element 820 gespeichert. Sobald eine aktualisierte Leerlaufdauervorhersage 816 bereitgestellt ist, ist der Vorhersagezyklus im Wesentlichen ausgeführt. Daher wird in Antwort auf eine Anfrage von Software-Entität 740, in einen angefragten Leistungszustand, wie z. B. C3, einzutreten, Power-Manager 715 ein neu aktualisierter, vorhergesagter Leerlaufdauer/Leistungszustand – lange Leerlaufdauer entsprechend einem C6-Leistungszustand – bereitgestellt. Power-Manager 715 trifft die Auswahl zwischen dem angefragten C3-Leistungszustand und dem vorhergesagten C6-Leistungszustand.
• Bei einer Ausführungsform wird diese Auswahl basierend auf der Genauigkeit von Vorhersagelogik 720 getroffen. Geht man zu Break-Even-Logik 810 zurück, wird die lange/kurze Leerlaufdauerbestimmung ebenfalls der Intervallgenauigkeitsbestimmungslogik bereitgestellt. Zusätzlich wird der vorherige, in Element 820 vor der Aktualisierung durch Zustandsmaschine 815 enthaltene Zustand ebenfalls Logik 825 bereitgestellt. Im Wesentlichen wird die vorher vorhergesagte Leerlaufdauer mit der neu gemessenen Dauer in der Form verglichen, dass verglichen wird, ob die gemessene Leerlaufdauer und vorhergesagte Leerlaufdauer beide lange Leerlaufdauern oder kurze Leerlaufdauern waren. Mit anderen Worten bestimmt Logik 825, ob die Vorhersage der Leerlaufdauer von Kern 701 richtig war.
• Eine Intervallgenauigkeitsbestimmungslogik stellt eine Genauigkeitsbestimmung 826 bereit. Wenn bei einer Ausführungsform die Vorhersage genau war, ist Signal 826 ein Erhöhungssignal, um Genauigkeitslogik 830 zu erhöhen. Wenn die Vorhersage nicht richtig war, beinhaltet Signal 826 ebenso ein Nicht-Erhöhungssignal. Demzufolge zählt Genauigkeitslogik 830 im Wesentlichen die Anzahl an Leerlaufintervallen, bei denen die Vorhersagelogik richtig war. Des Weiteren wird bei jeder Leerlaufdauermessung die Gesamtintervall-Verfolgungslogik 830 erhöht. Folglich ist die Anzahl genauer Leerlaufintervalle für Kern 701 in Genauigkeitslogik 830 verfügbar und die Gesamtanzahl an Intervallen ist in Intervall-Verfolgungslogik 830 verfügbar. Daher kann Genauigkeitslogik 830 die Anzahl genauer Intervalle durch die Gesamtintervalle teilen, um einen Genauigkeitswert 831, wie z. B. einen Genauigkeitsprozentsatz, zu erhalten.
• Demzufolge können Power-Manager 715 oder Genauigkeitslogik 830 diesen Genauigkeitswert mit einem Grenzwert, wie z. B. 90%, vergleichen. Wenn die Genauigkeit den 90%-Grenzwert übersteigt, dann wird der von Hardware vorhergesagte Zustand C6 für Kern 701 eingesetzt. Wenn die Genauigkeit stattdessen den 90%-Grenzwert nicht übersteigt, dann wird der angefragte Leistungszustand für Kern 701 eingesetzt. Es ist zu beachten, dass Genauigkeitslogik bei einem weiteren Beispiel leicht umgekehrt sein kann, wobei ein Zähler in Genauigkeitslogik 830 auf ungenaue Leerlaufintervalle erhöht wird und durch die Gesamtanzahl an Intervallen geteilt wird, um einen Ungenauigkeitswert zu erhalten. Dieser Wert kann dann mit einem Ungenauigkeitsgrenzwert, wie z. B. 10%, verglichen werden. Bei Betrieb sind die Verwendungen im Wesentlichen dieselben. Es ist zu beachten, dass Genauigkeitsgrenzwerte sowie der Rest der Anzahlen und Zustände, die bei dem Beispiel bereitgestellt sind, das auf 8 Bezug nimmt, rein veranschaulichend sind. Zusätzlich können Grenzwerte, wie z. B. ein Break-Even-Grenzwert oder Genauigkeitsgrenzwert durch Hardware, privilegierte Software, Benutzersoftware oder eine Kombination davon dynamisch einstellbar sein.
• Wendet man sich 9a–9b zu, ist eine Ausführungsform eines Verfahrens zum Vorhersagen einer Leerlaufdauer und zum Bestimmen der Genauigkeit solch einer Vorhersage veranschaulicht. Bei Ablauf 901 wacht ein Kern aus einem Leerlauf- oder Nicht-Aktiv-Zustand auf oder tritt aus einem solchen aus. Es ist zu beachten, dass der Kern Teil einer Gruppe von Kernen oder eines gesamten Prozessors sein kann, die/der aufwacht. Während des Leerlaufs, wird die Leerlaufdauer bei Ablauf 905 gemessen/bestimmt. Beispielsweise zählt ein Zähler die Dauer des Leerlaufs.
• Bei Ablauf 910 wird eine Gesamtleerlaufzählung bestimmt. Als Beispiel wird bei jedem Leerlaufintervall die Gesamtleerlaufzählung erhöht. Bei Ablauf 915 wird bestimmt, ob die Leerlaufdauer größer ist als ein Break-Even-Grenzwert, wie z. B. eine Break-Even-Zeit eines Leistungszustands. Wenn die Leerlaufdauer nicht größer ist als der Break-Even-Grenzwert, dann wird bestimmt, dass die Leerlaufdauer bei Ablauf 920 kurz war. Wenn die Leerlaufdauer ebenso größer ist als der Break-Even-Grenzwert, dann wird bestimmt, dass die Leerlaufdauer bei Ablauf 925 lang war. Indem kurz erneut auf 9b Bezug genommen wird, ist eine Zustandsmaschine veranschaulicht, die basierend auf der Bestimmung in Abläufen 920, 925 zwischen Zuständen verschiebt. Wenn beispielsweise die Leerlaufdauer lang ist, wie bei Ablauf 925, verschiebt die Zustandsmaschine durch Zustände 816a–816d in Richtung längerer Leerlaufzustände. Und umgekehrt verschiebt eine kurze Leerlaufdauerbestimmung 920 die Zustände in Richtung kürzerer Leerlaufzustände, wie z. B. in Richtung Zustand 816a.
• Des Weiteren wird bei Abläufen 930–945 eine Vorhersagegenauigkeit der Vorhersage-Hardware bestimmt. Wenn hier die Leerlaufdauer bei Ablauf 920 als kurz bestimmt wird, dann gibt es zwei mögliche Genauigkeitsergebnisse von Ablauf 930: (1) der vorher vorhergesagte Leerlaufzustand war richtig – die vorhergesagte Leerlaufdauer war entweder Zustand 816a oder 816b, die kurze Leerlaufdauern darstellen; oder (2) der vorher vorhergesagte Leerlaufzustand war nicht richtig – die vorhergesagte Leerlaufdauer war entweder Zustand 816c oder 816d, die lange Leerlaufdauern darstellen. Ebenso gibt es bei Ablauf 935 zwei ähnliche Ergebnisse: (1) der vorher vorhergesagte Leerlaufzustand war richtig – die vorhergesagte Leerlaufdauer war entweder Zustand 816c oder 816d, die lange Leerlaufdauern darstellen; oder (2) der vorher vorhergesagte Leerlaufzustand war nicht richtig – die vorhergesagte Leerlaufdauer war entweder Zustand 816a oder 816b, die kurze Leerlaufdauern darstellen. Wenn demzufolge die Vorhersage von beiden Pfaden richtig ist, wird die Genauigkeitszählung bei Ablauf 940 erhöht. Wenn die Vorhersage nicht richtig war, dann bewegt sich der Ablauf zu Ablauf 945, der einen Genauigkeitswert bestimmt, indem die Genauigkeitszählung durch die Gesamtleerlaufzählung von Ablauf 910 geteilt wird. Wenn daher die Genauigkeit über einer Grenzwertgenauigkeit liegt, dann wird der von Hardware vorhergesagte Leistungszustand für Kern 701 verwendet. Und wenn im Gegensatz dazu die Genauigkeit nicht über der Grenzwertgenauigkeit liegt, dann wird der angefragte Leistungszustand für Kern 701 verwendet. Die Kombination der Software-Anfragen und genauen Hardware-Vorhersage führt potentiell zu einer Auswahl sehr genauer Leistungszustände, wie z. B. der zu plus 94% richtigen Auswahl wie simuliert.
• Ein Modul wie hierin verwendet bezieht sich auf jede Hardware, Software, Firmware oder eine Kombination davon. Modulgrenzen, die als getrennt veranschaulicht sind, variieren herkömmlicherweise oftmals und können potentiell überlappen. Beispielsweise können ein erstes und ein zweites Modul Hardware, Software, Firmware oder eine Kombination davon gemeinsam benutzen, während einige unabhängige Hardware, Software oder Firmware potentiell zurückgehalten wird. Bei einer Ausführungsform beinhaltet eine Verwendung des Begriffes Logik Hardware, wie z. B. Transistoren, Register oder andere Hardware, wie z. B. programmierbare Logikbaugruppen. Bei einer weiteren Ausführungsformen jedoch beinhaltet Logik ebenfalls in Hardware integrierte Software oder Code, wie z. B. Firmware oder Mikrocode.
• Ein Wert wie hierin verwendet beinhaltet jede bekannte Darstellung einer Anzahl, eines Zustands, eines logischen Zustands oder eines binären logischen Zustands. Die Verwendung von Logik-Leveln, Logikwerten oder logischen Werten wird oftmals ebenfalls als 1-en und 0-en bezeichnet, was einfach binäre logische Zustände darstellt. Beispielweise bezieht sich eine 1 auf einen hohen Logik-Level und 0 bezieht sich auf einen niedrigen Logik-Level. Bei einer Ausführungsform kann eine Speicherzelle, wie z. B. ein Transistor oder eine Flash-Zelle, einen einzelnen logischen Wert oder mehrere logische Werte enthalten. Es wurden jedoch andere Darstellungen von Werten bei Computersystemen verwendet. Die Dezimalzahl Zehn beispielsweise kann ebenfalls als ein binärer Wert 1010 und ein hexadezimaler Buchstabe A dargestellt werden. Deshalb beinhaltet ein Wert jede Darstellung von Informationen, die in einem Computersystem enthalten sein können.
• Außerdem können Zustände durch Werte oder Teile von Werten dargestellt sein. Als Beispiel kann ein erster Wert, wie z. B. eine logische Eins, einen Standard- oder Anfangszustand darstellen, während ein zweiter Wert, wie z. B. eine logische Null, einen nicht standardmäßigen Zustand darstellen kann. Zusätzlich beziehen sich bei einer Ausführungsform die Begriffe Zurücksetzen und Setzen auf einen Standard- und einen aktualisierten Wert bzw. Zustand. Ein Standwert beinhaltet beispielsweise potentiell einen hohen logischen Wert, d. h. Zurücksetzen, während ein aktualisierter Wert potentiell einen niedrigen logischen Wert beinhaltet, d. h. Setzen. Es ist zu beachten, dass jegliche Kombination von Werten eingesetzt werden kann, um eine beliebige Anzahl an Zuständen darzustellen.
• Die Ausführungsformen der vorstehend angeführten Verfahren, Hardware, Software, Firmware oder Code können durch Befehle oder Code implementiert sein, die/der auf einem maschinenzugänglichen oder maschinenlesbaren Medium gespeichert sind und durch ein Verarbeitungselement ausgeführt werden können. Ein maschinenzugängliches/-lesbares Medium beinhaltet jeglichen Mechanismus, der Informationen in einer von einer Maschine lesbaren Form, wie z. B. einem Computer oder Elektronik, bereitstellt (d. h. speichert und/oder überträgt). Ein maschinenzugängliches Medium beispielsweise beinhaltet Direktzugriffsspeicher (random-access memory, RAM), wie z. B. statischen RAM (static RAM, SRAM) oder dynamischen RAM (dynamic RAM, DRAM); ROM; ein magnetisches oder optisches Speichermedium; Flash-Memory-Geräte; ein elektrisches Speichergerät, optische Speichergeräte, akustische Speichergeräte oder eine andere Form eines Speichergerätes mit ausgebreitetem Signal (z. B. Trägersignale, Infrarotsignale, digitale Signale) etc. Beispielsweise kann eine Maschine auf ein Speichergerät zugreifen, indem sie ein ausgebreitetes Signal, wie z. B. ein Trägersignal, von einem Medium empfängt, das die auf dem ausgebreiteten Signal zu übertragenden Informationen enthalten kann.
• Verweise in dieser Beschreibung auf „eine Ausführungsform” bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Charakteristikum, das in Verbindung mit der Ausführungsform beschrieben wird, mindestens in einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit beziehen sich die Verwendungen des Ausdrucks „bei einer Ausführungsform” an verschiedenen Stellen in dieser Beschreibung nicht notwendigerweise alle auf die gleiche Ausführungsform. Des Weiteren können die bestimmten Merkmale, Strukturen oder Charakteristika auf jegliche geeignete Weise bei ein oder mehr Ausführungsformen kombiniert sein.
• Bei der vorstehenden Beschreibung wurde eine ausführliche Beschreibung mit Bezug auf spezifische beispielhafte Ausführungsformen gegeben. Es ist jedoch offensichtlich, dass verschiedene Modifizierungen und Änderungen daran vorgenommen werden können, ohne vom weiteren Sinn und Umfang der Erfindung, wie in den angehängten Ansprüchen angeführt, abzuweichen. Die Beschreibung und Zeichnungen sind demnach eher in veranschaulichendem Sinne als in einschränkendem Sinne anzusehen. Des Weiteren bezieht sich die vorstehende Verwendung von Ausführungsform und anderer beispielhafter Sprache nicht notwendigerweise auf die gleiche Ausführungsform oder das gleiche Beispiel, sondern kann sich auf unterschiedliche und verschiedene Ausführungsformen sowie potentiell die gleiche Ausführungsform beziehen.

Claims (25)

1. Vorrichtung, umfassend: eine Vielzahl von N Prozessorkernen (301–304); einer Core-Hopping-Hardware, um einen oder mehrere Hardware-Thread-Kontexte von einem Kern zu einem anderen Kern zu migrieren; einem Aktivitätsmonitor (430), um Informationen über derzeitige oder vergangene Leistungszustände der N Kerne zu empfangen und um Daten in einem Aufzeichnungsintervall aufzuzeichnen, die anzeigen, wann und wie lange sich jeder Kern in einem bestimmten Leistungszustand befand; einen Prädiktor (435), der die während eines Aufzeichnungsintervalls aufgezeichneten Daten verwendet, um Verweilzeiten für Musterverteilungen von Kern-Leistungszuständen der N Prozessorkerne für das nächste Aufzeichnungsintervall vorherzusagen, einen Core-Hop-Manager (440), der basierend auf den vorhergesagten Verweilzeiten der Musterverteilungen im nächsten Aufzeichnungsintervall eine Migration eines Hardware-Kontexts von einem der Prozessorkerne zu einem anderen auf eine Anfrage hin als für eine Wärmeabfuhr effizient erlaubt oder als ineffizient verweigert.
2. Vorrichtung nach Anspruch 1, wobei der Prädiktor (435) eingerichtet ist, eine erste Residenz eines ersten Leerlauf-Beschäftigt-Musters für das zukünftige Intervall vorherzusagen.
3. Vorrichtung nach Anspruch 2, wobei das erste Leerlauf-Beschäftigt-Muster für das zukünftige Intervall ein erstes Leerlauf-Beschäftigt-Gesamtmuster umfasst, das eine Zusammenfassung einer Anzahl effizienter Core-Hopping Leerlauf-Beschäftigt-Muster sein soll.
4. Vorrichtung nach Anspruch 3, wobei der Core-Hopping-Manger (440) eingerichtet ist, in Antwort auf die erste Residenz des ersten Leerlauf-Beschäftigt-Gesamtmusters, die über einem Grenzwert liegt, zu bestimmen, dass das Core-Hopping effizient ist, und um in Antwort auf die erste Residenz des ersten Leerlauf-Beschäftigt-Gesamtmusters, die nicht über dem Grenzwert liegt, zu bestimmen, dass das Core-Hopping nicht effizient ist.
5. Vorrichtung nach Anspruch 1, wobei der Prädiktor (435) eingerichtet ist, vergangene Aktivität der Vielzahl an Prozessorkernen (301–304) während eines vorherigen Intervalls als die zukünftige Aktivität der Vielzahl an Prozessorkernen (301–304) für das zukünftige Intervall einzusetzen.
6. Vorrichtung nach Anspruch 1, wobei der Prädiktor (435) eingerichtet ist, einen Aktivitätshinweis von einer Software-Entität zu empfangen und die zukünftige Aktivität für das zukünftige Intervall basierend auf dem Aktivitätshinweis von der Software-Entität vorherzusagen.
7. Vorrichtung nach Anspruch 1, weiter umfassend eine Core-Hopping-Auslöselogik, um ein Core-Hop-Ereignis basierend auf zumindest einer thermischen Dichte-Bedingung zu generieren, wobei das Core-Hop-Ereignis eine Anfrage beinhaltet, einen Core-Hop durchzuführen, und wobei der Core-Hopping-Manager (440) eingerichtet ist, die Anfrage zum Durchführen des Core-Hops abzulehnen.
8. Vorrichtung nach Anspruch 7, wobei der Core-Hopping-Manager (440) eingerichtet ist, zu bestimmen, ob die zukünftige Aktivität der Vielzahl an Prozessorkernen anzeigt, dass ein Core-Hop machbar ist, um die thermische Dichte-Bedingung zu erleichtern.
9. Vorrichtung nach Anspruch 1, wobei die Vielzahl an Kernen (301–304), der Prädiktor (435) und der Core-Hopping-Manger (440) in einem Mikroprozessor beinhaltet sind, wobei der Mikroprozessor mit einem Speicher gekoppelt ist, wobei der Speicher ausgewählt ist aus der Gruppe umfassend einen dynamischen Direktzugriffsspeicher, Double Data Rate RAM und einen statischen Direktzugriffsspeicher.
10. Vorrichtung nach Anspruch 1, weiter umfassend: Core-Hopping-Logik, die mit der Vielzahl an Kernen (301–304) gekoppelt ist, um eine Core-Hop-Anfrage auszulösen; Core-Hop-Manager-Logik, die mit der Core-Hopping-Logik und dem Prädiktor (435) gekoppelt ist, wobei die Core-Hop-Manager-Logik die Core-Hop-Anfrage in Antwort auf den Core-Hop-Manager (440) ablehnen soll, der die Aktivität der Vielzahl an Kernen für das nächste Intervall bestimmt, das anzeigt, dass Core-Hopping ineffizient ist.
11. Vorrichtung nach Anspruch 10, wobei die Core-Hopping-Logik zum Auslösen einer Core-Hop-Anfrage auf einer thermischen Dichte-Bedingung basiert.
12. Vorrichtung nach Anspruch 11, wobei die Aktivität der Vielzahl an Kernen (301– 304) eine vorhergesagte Residenz eines Aktivitäts-Gesamtmusters während des nächsten Intervalls beinhaltet.
13. Vorrichtung nach Anspruch 12, wobei die Vielzahl an Kernen (301–304) N Kerne beinhaltet und eine Anzahl möglicher Aktivitätsmuster 2^N Muster beinhaltet, und wobei das Aktivitäts-Gesamtmuster eine Untermenge der 2^N Aktivitätsmuster beinhaltet, die machbar ist, um die thermische Dichte-Bedingung zu erleichtern.
14. Vorrichtung nach Anspruch 13, wobei der Core-Hop-Manager (440) weiter eingerichtet ist, die vorhergesagte Residenz, die eine Grenzwert-Residenz nicht übersteigt, der Untermenge der 2^N Aktivitätsmuster zu bestimmen, die machbar ist, um die thermische Dichte-Bedingung zu erleichtern.
15. Vorrichtung nach Anspruch 14, wobei der Core-Hop-Manager (440) eingerichtet ist, reagierend auf die Core-Hop-Anfrage einen Core-Hop zu initiieren, um die thermische Dichte-Bedingung in Antwort auf den Core-Hop-Manager (440) zu erleichtern, und eingerichtet ist, die vorhergesagte Residenz, die die Grenzwert-Residenz übersteigt, der Untermenge der 2^N Aktivitätsmuster zu bestimmen, die machbar ist, um die thermische Dichte-Bedingung zu erleichtern.
16. Vorrichtung nach Anspruch 14, wobei der Core-Hop-Manager (440) eingerichtet ist, ein optimales Aktivitätsmuster zu bestimmen, um die thermische Dichte-Bedingung zu erleichtern, und um zumindest den Core-Hop zu initiieren, um das optimale Aktivitätsmuster zu erhalten.
17. Vorrichtung nach Anspruch 10, wobei die Vielzahl an Kernen (301–304), die Core-Hopping-Logik, der Prädiktor (435) und die Core-Hop-Manager-Logik in einem Mikroprozessor beinhaltet sind, wobei der Mikroprozessor mit einem Speicher gekoppelt ist, wobei der Speicher ausgewählt ist aus der Gruppe umfassend einen dynamischen Direktzugriffsspeicher, einen Double Data Rate RAM und einem statischen Direktzugriffsspeicher.
18. Verfahren zur Durchführung in der Vorrichtung gemäß Anspruch 1, umfassend: Empfangen von Informationen über derzeitige oder vergangene Leistungszustände von N-Kernen und Aufzeichnen von Daten in einem Aufzeichnungsintervall, die anzeigen, wann und wie lange sich jeder Kern in einem bestimmten Leistungszustand befand; Verwenden der während eines Aufzeichnungsintervalls aufgezeichneten Daten, um Verweilzeiten für Musterverteilungen von Kern-Leistungszuständen der N-Prozessorkerne für das nächste Aufzeichnungsintervall vorherzusagen; basierend auf den vorhergesagten Verweilzeiten der Musterverteilungen im nächsten Aufzeichnungsintervall Erlauben einer Migration eines Hardware-Kontexts von einem der Prozessorkerne zu einem anderen auf eine Anfrage hin als für eine Wärmeabfuhr effizient oder als ineffizient zu verweigern.
19. Verfahren nach Anspruch 18, wobei eine Leerlauf-Aktivitäts-Darstellung eine erste Zusammenfassung einer ersten Anzahl an Leerlauf-Aktivitätsmustern einer Gesamtanzahl möglicher Leerlauf-Aktivitätsmuster beinhaltet, wobei die erste Anzahl an Leerlauf-Aktivitätsmustern für Core-Hopping effizient sein soll.
20. Verfahren nach Anspruch 19, wobei die erste Anzahl an Leerlauf-Aktivitätsmustern, die für Core-Hopping effizient sein soll, auf einer Richtlinie basieren soll, die eine zeitliche Benachteiligung, die mit einem Durchführen des Core-Hops verbunden ist, und eine Verstärkung der thermischen Dichte, die mit einem Durchführen des Core-Hops verbunden ist, gewichtet.
21. Verfahren nach Anspruch 20, wobei die Richtlinie, die die zeitliche Benachteiligung, die mit einem Durchführen des Core-Hops verbunden ist, und eine Verstärkung der thermischen Dichte, die mit einem Durchführen des Core-Hops verbunden ist, gewichtet, die Richtlinie umfasst, um die Gesamtanzahl möglicher Leerlauf-Aktivitätsmuster zu gruppieren in: die erste Anzahl an Leerlauf-Aktivitätsmustern in Antwort auf die erste Anzahl an Leerlauf-Aktivitätsmustern, die mit einer Machbarkeit für Core-Hopping verbunden ist, eine zweite Anzahl an Leerlauf-Aktivitätsmustern der Gesamtanzahl an Leerlauf-Aktivitätsmustern in Antwort auf die zweite Anzahl an Leerlauf-Aktivitätsmustern, die mit einer minimalen Verstärkung der thermischen Dichte verbunden ist, und eine dritte Anzahl an Leerlauf-Aktivitätsmustern der Gesamtanzahl an Leerlauf-Aktivitätsmustern in Antwort auf die dritte Anzahl an Leerlauf-Aktivitätsmustern, die mit einer Nicht-Machbarkeit für Core-Hopping verbunden ist.
22. Verfahren nach Anspruch 18, weiter umfassend ein Generieren einer Core-Hop-Anfrage in Antwort auf eine thermische Dichte-Bedingung.
23. Verfahren nach Anspruch 18, wobei ein Residenz-Grenzwert durch eine privilegierte Entität dynamisch einstellbar ist.
24. Computerlesbares Medium einschließlich Programmcode, der, wenn er von einer Maschine ausgeführt wird, das Verfahren nach Anspruch 18 durchführen soll.
25. Vorrichtung, umfassend Mittel zum Durchführen des Verfahrens nach Anspruch 18.

Images