DE69816686T2

DE69816686T2 - Hochfrequenzabtastung von Leistungszählern

Info

Publication number: DE69816686T2
Application number: DE69816686T
Authority: DE
Inventors: Lance M. Berc; Richard L. Sites; Carl A. Waldspurger; Sanjay Ghemwat; Monika H. Henzinger; William Weihl
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1997-03-10
Filing date: 1998-03-09
Publication date: 2004-06-03
Anticipated expiration: 2018-03-10
Also published as: EP0864978B1; US5796939A; JP4209959B2; DE69816686D1; EP0864978A3; CA2231584A1; JPH10260869A; EP0864978A2

Description

BEREICH DER ERFINDUNG
Die vorliegende Erfindung betrifft im allgemeinen Computersysteme und im besonderen die Erfassung von Leistungsdaten in Computersystemen.
HINTERGRUND DER ERFINDUNG
Die Erfassung von Leistungsdaten aus einem in Betrieb befindlichen Computersystem ist eine äusserst wichtige und von Hardware- und Softwaretechnikern häufig durchzuführende Aufgabe. Hardwaretechniker sind auf Leistungsdaten angewiesen, um zu bestimmen wie neue Computerhardware mit bestehenden Betriebssystemen und Anwendungsprogrammen zusammenarbeitet.
Spezifische Ausgestaltungen von Hardwarestrukturen, wie zum Beispiel Prozessor, Speicher und Cachespeicher gehen oft in äusserst verschiedener, und manchmal unvorhersehbarer Art und Weise mit ein und derselben Gruppe von Programmen um. Es ist wichtig, Schwachstellen in der Hardware zu erkennen, damit diese in zukünftigen Ausgestaltungen korrigiert werden können. Leistungsdaten ermöglichen es, festzustellen, wie effizient die Software die Hardware nutzt, und sie können auch beim Entwurf verbesserter Systeme hilfreich sein.
Softwaretechniker müssen oft kritische Programmabschnitte erkennen. Die Programmierer von Compilerprogrammen wären zum Beispiel interessiert, zu wissen, nach welchem Plan der Compiler die Befehle zur Abarbeitung bereitlegt, oder mit welcher Wahrscheinlichkeit vorhergesagt werden kann, dass durch die Ausführung von bedingten Verzweigungen Eingangsdaten für die Softwareoptimierung bereitgestellt werden können. In ähnlicher Weise ist es wichtig, die Leistung des Betriebssystemkerns, der Gerätetreiber und der Anwendungssoftwareprogramme zu verstehen.
Die genaue Überwachung der Leistung von Hardware- und Softwaresystemen, ohne dabei Störungen des Betriebsumfeldes des Computersystems zu verursachen, stellt ein Problem dar, insbesondere dann, wenn die Leistungsdaten über längere Zeiträume hinweg, wie etwa mehrere Tage oder Wochen, gewonnen werden sollen. In vielen Fällen handelt es sich bei den Leistungsüberwachungssystemen um spezielle Einzelanfertigungen. Unter Umständen ist es erforderlich, kostspielige Veränderungen an Hard- und Software vorzunehmen, um zu gewährleisten, dass bestimmte Betriebsoperationen des Systems durch die Überwachungssysteme nicht negativ beeinflusst werden.
Eine Art, die Leistung eines Computersystems zu überwachen, besteht im Einsatz von Leistungszählern. Leistungszähler "zählen" das Auftreten von bedeutenden Ereignissen in dem System. Bedeutende Ereignisse sind zum Beispiel unter anderem Cachefehlgriffe, ausgeführte Befehle, E/A-Datentransferanforderungen und dergleichen. Durch periodisches Abtasten der Leistungszähler können Rückschlüsse auf die Leistung des Systems gezogen werden.
Es ist wünschenswert, die Leistung eines Computersystems überwachen zu können, ohne dadurch Veränderungen bei der Software zu verursachen. Ebenfalls wünschenswert ist es, dass die Abtastrate fix oder veränderlich gestaltet werden kann und dass die Rate sehr hoch sein kann. Darüber hinaus ist es wünschenswert, während der Hochfrequenzabtastung den Steuerungsaufwand der Abtastung möglichst gering zu halten, so dass die Leistungsdaten ein genaues Abbild von dem Betrieb des Systems liefern. Den Steuerungsaufwand gering zu halten gestaltet sich besonders bei einer Mehrfachprozessoranlage besonders schwierig, da hier die Datenzugriffe synchronisiert erfolgen müssen und die Abtastrate sehr hoch sein kann und beispielsweise bei 50 000 bis 100 000 Abtastwerten pro Sekunde liegen kann.
In der JP-A-05002508 wird ein Programmleistungsanalysator für ein Computersystem mit einer Mehrzahl von Prozessoren beschrieben, von denen ein jeder eine Mehrzahl von Zählern zur Messung der Ausführungshäufigkeit und der Unterbrechungshäufigkeit von Befehlen in dem Prozessor beinhaltet, sowie eine Einrichtung, die es erlaubt, wenn Interrupts generiert werden, die Inhalte dieser Zähler zu erfassen, um sie in eine Abtastinformationsdatei zu verschieben.
KURZDARSTELLUNG DER ERFINDUNG
Die Erfindung schafft eine Vorrichtung zur Erfassung von Leistungsdaten in einem Computersystem. Das Computersystem beinhaltet eine Mehrzahl von Prozessoren zur gleichzeitigen Ausführung von Befehlen eines Programms. Die Vorrichtung umfasst eine Mehrzahl von Leistungszählergruppen. Mit jedem Prozessor ist jeweils eine Gruppe von Leistungszählern verbunden. Die Leistungszähler dienen der Speicherung von Leistungsdaten, welche von jedem Prozessor während der Befehlsausführung generiert werden.
Die Erfindung in ihrer allgemeinen Form besteht in einer Vorrichtung zur Erfassung von Leistungsdaten in einem Com putersystem gemäß Anspruch 1 und in einem entsprechenden Verfahren gemäß Anspruch 14.
Auf jedem Prozessor wird eine Interruptbehandlungsroutine ausgeführt. Die Interruptbehandlungsroutine dient dazu, in Reaktion auf entsprechende Interrupts die Leistungsdaten des Prozessors abzutasten. Ein erster Speicher beinhaltet eine Hash-Tabelle welche jeder Interruptbehandlungsroutine zugeordnet ist. Die Hash-Tabelle speichert die Leistungsdaten, welche von der auf dem Prozessor laufenden Interruptbehandlungsroutine abgetastet werden. Ein zweiter Speicher beinhaltet einen Überlauf-Pufferspeicher, welcher der Speicherung von Leistungsdaten dient, während Abschnitte der Hash-Tabellen inaktiv sind und während diese Abschnitte voll sind. Ein dritter Speicher beinhaltet einen Benutzer-Pufferspeicher. Ausserdem ist eine Einrichtung zum periodischen Entleeren der Leistungsdaten aus den Hash-Tabellen und dem Überlauf-Pufferspeicher in den Benutzer-Pufferspeicher vorgesehen.
Vorzugsweise ist die Hash-Tabelle des ersten Speichers, wie im folgenden beschrieben, als mehrwegiger Cache mit teilassoziativer Abbildung organisiert. Darüber hinaus beinhaltet der mehrwegige Cache mit teilassoziativer Abbildung eine Mehrzahl von Datenblöcken, wobei ein jeder Datenblock eine Datenübertragungseinheit zwischen dem ersten und dem dritten Speicher darstellt. Jeder Datenblock umfasst weiterhin eine Mehrzahl von Zeilen, und mit jedem Datenblock ("chunk") ist ein "active_chunk"-Flag und ein "flushchunk"-Flag verbunden, um jeweils anzuzeigen, ob der entsprechende Datenblock inaktiv ist bzw. voll ist. Die Zeilen eines jeden Datenblocks sind weiterhin in eine Mehrzahl von Einträgen unterteilt, und jeder Eintrag beinhaltet eine Mehrzahl von Feldern zur Speicherung der Leistungsdaten. Die Felder der Leistungsdaten beinhalten eine Prozessoridentifikation, einen Programmzähler, eine Prozessorereigniskennzeichnung und ein Prozessorereigniszählerfeld.
Vorteilhafterweise ist eine Einrichtung zum Generieren eines Hash-Indexes aus der Prozesskennzeichnung, dem Programmzähler und der Prozessorereigniskennzeichnung vorgesehen. Der Hash-Index wird dazu verwendet, um die Zeilen der einem bestimmten Prozessor zugeordneten Hash-Tabelle zu prüfen, um ein Treffer- bzw. Fehlgriffsignal zu generieren.
In Reaktion auf ein Fehlgriffsignal werden die in einem aktuellen Eintrag durch einen aktuellen Hash-Index indizierten Leistungsdaten von der Hash-Tabelle in den Überlauf-Pufferspeicher verschoben. Der aktuelle Eintrag wird mit den von der Interruptbehandlungsroutine abgetasteten Leistungsdaten überschrieben. Im Fall eines Treffersignals wird der an dem von dem aktuellen Hash-Index indizierten, aktuellen Eintrag gespeicherte Prozessorereigniszähler inkrementiert. Die Leistungsdaten werden in den Einträgen in komprimierter Form gespeichert.
Wie im folgenden gezeigt, beinhaltet der Überlauf-Pufferspeicher des zweiten Speichers einen erste und einen zweiten Puffer, die als Doppelpuffer organisiert sind. Jeder Puffer beinhaltet eine Mehrzahl freier Plätze zum Abspeichern der Leistungsdaten aus den Einträgen der Hash-Tabellen.
KURZBESCHREIBUNG DER ZEICHUNGEN
Ein genaueres Verständnis der Erfindung kann aus der nachfolgenden Beschreibung von bevorzugten Ausführungsformen gewonnen werden, welche beispielhaften Charakter hat und in Verbindung mit den beigefügten Zeichnungen zu verstehen ist, in denen:
1 ein Blockdiagramm eines Computersystems darstellt, dessen Leistungdaten durch ein Leistungsüberwachungs-Subsystem gemäss einer bevorzugten Ausführungsform der Erfindung erfasst werden können;
2 ein Blockdiagramm des Datenerfassungs-Subsystems darstellt;
3 ein Blockdiagramm einer Hash-Tabelle zum Abspeichern erfasster Leistungsdaten darstellt;
4 ein Ablaufdiagramm für die Aktualisierung der Hash-Tabelle aus 3 darstellt;
5 ein Taktdiagramm der unsynchronisierten Aktualisierung der Hash-Tabelle darstellt;
6 Variablen zeigt, die von einer Interruptbehandlungsroutine und einer Hash-Tabellenentleerungsroutinegemeinsam genutzt werden;
7 Pseudocode für eine Interruptbehandlungsroutine darstellt;
8 Pseudocode für das Entleeren einer Hash-Tabelle darstellt;
9 gemeinsam genutzte Synchronisationsvariablen darstellt;
10 Pseudocode für das Erfassen eines freien Platzes in einem Überlauf-Pufferspeicher darstellt;
11 Pseudocode für das Schreiben eines Eintrags in einen freien Platz des Überlauf-Pufferspeichers darstellt;
12 Pseudocode für das Entleeren des Überlauf-Pufferspeichers darstellt;
13 Pseudocode für die Behandlung von Überlauf-Pufferspeicherereignissen darstellt, die während Abtastereignis-Interrupts stattfinden;
14 Pseudocode für das Entleeren einer Hash-Tabelle darstellt; und
15 Pseudocode für eine Routine zum Schreiben von Einträgen in den Überlauf-Pufferspeicher darstellt;
16 Pseudocode für eine Routine zum Entleeren des Überlauf-Pufferspeichers in einen Benutzer-Pufferspeicher darstellt.
DETAILLIERTE BESCRREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
Systemüberblick
Wie in 1 gezeigt, beinhaltet ein Computersystem 100 einen Prozessor 110, ein Speicher-Subsystem (Speicher) 120, Eingabe-/Ausgabeschnittstellen (R/A), welche durch einen Bus 140 untereinander verbunden sind. Bei dem System kann es sich um ein eingebettetes System, einen PC, eine Workstation, einen Grossrechner, oder um einen Teil eines Clusters von Systemen handeln, die durch ein Netzwerk miteinander verbundenen sind.
Der Prozessor 110 kann als ein oder als mehrere einzelne Prozessorchips 111 konfiguriert sein, die entweder über eine CISC- oder eine RISC-Architektur verfügen. Einem jeden Prozessor 111 ist eine Gruppe von Leistungszählern zugeordnet. Jede Gruppe von Leistungszählern 112 kann als eine Mehrzahl von Registern implementiert sein. Die Register können das Auftreten von bedeutenden Ereignissen in dem System zählen, welche über die Leistung des Systems Aufschluss geben.
Die Speicher 120 können separate, statische, dynamische, Direktzugriff-, flüchtige und dauerhafte Speicherelemente beinhalten. Manche der Speicher können hierarchisch angeordnet sein. Bei den Speicherelementen kann es sich um Register, Cachespeicher, DRAMs, Plattenspeicher, Bandspeicher und dergleichen handeln. Die Speicher 120 speichern Softwareprogramme 121 in Form von maschinenausführbaren Befehlen, und Daten 122, auf welche durch die Befehle zugegriffen wird. Die Softwareprogramme können ein Betriebssystem, Gerätetreiber und Anwendungsprogramme beinhalten.
Die E/A 130 kann Schnittstellen zu Eingabe- und Ausgabeeinrichtungen wie etwa Drucker, Terminals und Tastaturen beinhalten. Die E/A 130 kann auch über Leitungen 150 mit einem Netzwerk (NETZ) 160 zum Datenaustausch mit anderen Computersystemen verbundnen sein. Der Bus 140 ist typischerweise als eine Mehrzahl von Leitungen zur Übertragung von Adress-, Daten-, Steuer- und Taktsignalen zwischen den verschiedenen Elementen implementiert.
Funktionsüberblick
Während des Betriebs des Systems 100, werden die von den Programmen 121 kommenden Befehle von dem einen Prozessor 111 bzw. der Mehrzahl von Prozessoren 111 ausgeführt. Die Befehle steuern im allgemeinen entweder den Ausführungsablauf der Programme oder greifen (zu Lade-, Speicher-, Lese- und Schreibzwecken) auf die Daten 122 zu. Es ist wünschenswert, Leistungsdaten des Systems 100 zu erfassen, ohne dabei das normale Betriebsumfeld merklich zu stören.
Die Analyse der Leistungsdaten kann dazu genutzt werden, um den Entwurf von Hardware- und Softwarekomponenten des Systems 100 zu optimieren. Die Leistungsdaten können ausserdem dazu benutzt werden, um Probleme beim Betrieb, wie zum Beispiel Pipelineblockierungen festzustellen.
Datenerfassungs-Subsystem
In einer in 2 dargestellten Ausführungsform beinhaltet das Leistungsdatenerfassungssubsystem 200 verschiedene Hardwareeinrichtungen 220, Systemkernprogramme und -datenstrukturen 230 und Benutzerprogramme und -datenstrukturen 260. Die Programme und Daten 230 und 260 können in den Speichern 120 aus 1 abgespeichert werden.
Die Hardware 220 kann eine Mehrzahl von individuellem Prozessoren 221–223 beinhalten. Einem jeden Prozessor ist eine Gruppe von Leistungszählern bzw. Registern 201 zugeordnet. Die Gruppen von Registern 201 können mit dem zugeordneten Prozessor auf demselben Halbleiter-Chip koresident sein. Jede Gruppe 201 kann eine Mehrzahl von Registern 1 – M beinhalten.
Jedes der Register 1 – M kann eine Vielzahl von Bits zum Speichern von Leistungsereigniszählergebnissen beinhalten. Die Gesamtanzahl des Auftretens eines bestimmten Ereignisses, welche in einem jeden der Zähler akkumuliert werden kann, ist von der Grösse oder Bitanzahl der Register 1 – M abhängig.
Je nach spezifischer Implementierung können die Registergruppen 201 aktiviert, deaktiviert, angehalten, wieder zugeschaltet, zurückgesetzt (gelöscht), gelesen und beschrieben werden. Typischerweise generieren die Register im Fall eines Überlaufs Interrupts 251–253 (einen Übertrag in einer bestimmten Bitposition für die nächsthöhere Stelle). In Reaktion auf die Interrupts können die Register 201 abgetastet (gelesen) werden. Bei gewissen Implementierungen kann beim Setzen eines spezifischen Bits eines der Register auf Zählfrequenzen, welche ganzzahligen Potenzen von zwei entsprechen, ein Interrupt generiert werden.
Während des Betriebs der Hardware 220 bewirken die Signale oder "Ereignisse", z. B. (E₁, ..., E_M) 241–244, die verschieden Betriebsmerkmale des Systems darstellen, dass das entsprechende Register inkrementiert wird. Die genauen Ereignisse, welche signalisiert werden, sind gewöhnlich systemspezifischer Natur. Typische Ereignisse, welche die Register inkrementieren können, beinhalten zum Beispiel Cache-Fehlgriffe, Sprung-Fehlvorhersagen, Pipelineblockierungen, ausgegebene Befehle, arithmetische Operationen, Prozessorzyklen, Wiedergabe-Traps, Übersetzungspufferspeicher-Fehlgriffe, E/A-Anforderungen, aktive Prozesse und dergleichen. Ein oder eine bestimmte Anzahl von Ereignissen können jederzeit zur Abtastung ausgewählt werden.
Die Systemkernkomponenten 230 des Subsystems 200 beinhalten Gerätetreiber und Interruptbehandlungsroutinen (Programme) 231–233, sowie Tabellen 234–236. Für jeden der Prozessoren ist eine Behandlungsroutine und eine dieser zugeordnete Tabelle vorhanden. Über eine Hash-Tabelle pro Prozessor zu verfügen, bringt den Vorteil, dass es nicht mehr nötig ist, die meisten Verarbeitungsaktivitäten zwischen den einzelnen Prozessen zu synchronisieren. Ausserdem ist in einer Ausführungsform ein Überlauf-Pufferspeicher 238 vorgesehen, der von allen Behandlungsroutinen 231–233 gemeinsam genutzt wird. Der Zugriff auf den Pufferspeicher 238 wird durch eine Sperre (L) 239 gesteuert. In einer alternativen Ausführungsform kann jeder Behandlungsroutine ein privater Pufferspeicher zugeordnet werden, um die Anzahl der Ereignisse, die synchronisiert werden müssen, weiter zu reduzieren.
Während die Systemkernkomponenten 230 in Betrieb sind, aktiviert ein Interrupt eine entsprechende Behandlungsroutine. Die Behandlungsroutinen 231–233 können als mehrfach nebenläufig ausgeführte Prozesse oder Threads betrieben werden. Die Behandlungsroutinen lesen die Leistungsdaten aus den Registern und speichern die Daten in einer der zugeordneten Tabellen 234–236, wie weiter unten noch im Detail zu beschreiben sein wird. Falls eine der Tabellen voll wird bzw. nicht mehr darauf zugegriffen werden kann, so können die Überlauf-Daten in dem Überlauf-Pufferspeicher gespeichert werden. Um in den Pufferspeicher 238 schreiben zu können, muss ein Prozess sich zuerst die Sperre 239 übertragen lassen, damit die Konsistenz der Daten gewährleistet bleibt.
Die Benutzerkomponenten 260 beinhalten einen Dämonprozess 261, einen oder mehrere Benutzerpufferspeicher 262 und verarbeitete Leistungsdaten 251. Die Daten 251 können auf einem Plattenspeicher 250 oder auf anderen Arten von nichtflüchtigen Speichermedien gespeichert werden, die Teil der Speicher 120 aus 1 sein können.
Der Dämon 261 kann während des Betriebs periodisch die Hash-Tabellen und den Überlauf-Pufferspeicher in den Benutzer-Pufferspeicher 262 entleeren. Darüber hinaus kann der Dämon 261 ausserdem die akkumulierten Leistungsdaten weiterverarbeiten, um daraus zum Beispiel Ausführungsprofi- le, Histogramme und andere statistische Daten zusammenzustellen, welche für die Analyse der Leistung des Systems nützlich sind.
Hash-Tabelle
wie in 3 gezeigt, ist jede der Tabellen 234–236 als Hash-Tabelle 300 gestaltet. Eine Hash-Tabelle ist eine Datenstruktur, auf welche von einem Hash-Index zugegriffen wird. Typischerweise handelt es sich bei einem Hash-Index um eine deterministisch berechnete Adresse, die dazu neigt, Daten nach dem Zufallsprinzip über einen Adressenbereich zu verteilen.
Hashing-Funktionen sind allgemein bekannt. In der vorliegenden Ausführungsform der Leistungsdatenerfassung werden Hash-Tabellen dazu verwendet, um die Speicherbandbreite zu verringern, welche erforderlich ist, um Daten zwischen Systemkernprozessen und Benutzerprozessen zu übertragen. Im spezielleren kann eine Hash-Tabelle, wie nachfolgend beschrieben, als mehrwegiger Cache mit teilassoziativer Abbildung implementiert werden, um die Bandbreite für das Speicher-Subsystem zu verringern. Die bevorzugte Ausführungsform der Erfindung verwendet eine vierwegige, assoziative Darstellung in der Hash-Tabelle 300.
Die Hash-Tabelle 300 ist in eine Mehrzahl von Datenblöcken 301–202 unterteilt. Der Datenblock ist die Einheit des Datentransfers zwischen den Systemkernkomponenten und den Benutzerkomponenten. Jeder Datenblock der Hash-Tabelle 300 ist weiter unterteilt in eine Mehrzahl von Zeilen 311–314. Eine Zeile ist typischerweise eine zusammenhängende Datentransfereinheit, welche effizient von der Speicherübertra gungslogik und von den Cachespeichern des Systems verarbeitet wird.
Die Fähigkeit der (vierwegigen) teilassoziativen Abbildung der Hash-Tabelle 300 wird sorgfältig ausgewählt, um in ihrer Grösse mit der Grösse der Hardware-Cachespeicherzeilen 311–314 übereinzustimmen, wobei zum Beispiel jede Cachespeicherzeile 64 Bytes beinhaltet. Ausserdem ist einem jeden der Datenblöcke 301–303 ein "active_chunk"-Flag 315 und ein "flush_chunk"-Flag 316 zugeordnet. Das "activechunk"-Flag 315 kann gesetzt werden wenn eine der Behandlungsroutinen Daten modifiziert (aktualisiert), die in einem der Datenblöcke der Hash-Tabelle gespeichert sind. Wenn ein Flag aufgehoben ist, ist der entsprechende Datenblock inaktiv, bzw. wird er nicht gerade beschrieben. Das "flush_chunk"-Flag kann gesetzt werden, wenn Daten von einer Hash-Tabelle in einen Benutzer-Pufferspeicher kopiert werden. Im folgenden wird die unsynchronisierte Behandlung der Tabellen und Pufferspeicher genauer beschrieben.
Jede Zeile beinhaltet eine Mehrzahl von Einträgen mit teilassoziativer 320. Jeder Eintrag 320 beinhaltet eine Mehrzahl von Feldern 321–324. In den Feldern 321–324 wird zum Beispiel eine Prozessidentifikation (pid), ein Programmzähler (pc), eine Ereignisidentifikation (event) und ein Zählerwert (count) gespeichert. Die in den Einträgen 320 der Zeilen 311–314 gespeicherten Daten sind stark komprimiert, um die Anzahl von Cache-Fehlgriffen zu verringern. Indem die Fähigkeit der teilassoziativen Abbildung an die Grösse der Cachezeilen angepasst wird, können im Fall eines Cache-Fehlgriffs eine grösstmögliche Anzahl von Einträgen überprüft werden. Durch das Abspeichern der Abtastwerte als komprimierte Cache-Zeilen wird die benötigte Bandbreite reduziert und somit die Beanspruchung des Speichersubsystems 120 gering gehalten.
Interruptbehandlungsroutine-Prozess
In 4 wird ein Prozess 400 der Behandlungsroutinen aus 2 gezeigt. Der Prozess 400 dient dazu, die Einträge 320 der Zeilen der Hash-Tabelle 300 aus 3 zu aktualisieren. Der Prozess wird typischerweise als Reaktion auf ein Interrupt eingeleitet und beginnt bei Schritt 410. In Schritt 420 wird ein Hash-Index H_i bestimmt. Der Index kann durch eine Hash-Funktion f_hash bestimmt werden, welche die Bits, zum Beispiel ein ausschliessendes ODER dieses Vorkommens von pid_i, pc_i und event_i; zum Beispiel H_i = f_hash(pid_i, pc_i, event_i) kombiniert.
In schritt 430 werden alle Einträge für den Index H_i in der Tabelle 300 geprüft, um zu ermitteln, ob sie pid_i, pc_i, und event_i entsprechen. Im Fall eines Treffers wird das Zählerstandfeld 324 in Schritt 440 inkrementiert, d. h. count_i = count_i + 1.
Im Fall eines Fehlgriffs, d. h. wenn bei keinem der Einträge für den Index H_i ein Treffer verzeichnet wird, wird ein Eintrag bei Index H_i in Schritt 450 an den Überlauf-Pufferspeicher 238 aus 4 übertragen. In Schritt 460 wird der neue Eintrag an dem Index H_i in der Hash-Tabelle gespeichert und der Zählerstand auf 1 gesetzt. Ungeachtet dessen, ob es sich um einen Treffer oder einen Fehlgriff handelt, wird der Prozess immer in Schritt 490 beendet.
Eine spezielle Interruptbehandlungsroutine muss auf mehrere globale Datenelemente zugreifen. Die globalen Daten beinhalten den Zeiger in die Hash-Tabelle für den Prozessor auf welchem die Behandlungsroutine läuft, die Zeile der Hash-Tabelle, die von dem Wert der Hash-Funktion für den neuen Eintrag indiziert wird, die Zeiger in die Überlauf-Pufferspeicher, mehrere globale Variablen zur Steuerung des Zustands der Datenstrukturen (z. B. der als nächstes in den aktiven Überlauf-Pufferspeicher einzufügende Index, sowie ein Zähler, der angibt, welcher Eintrag in einer gegebenen Zeile beim nächsten Fehlgriff in der Hash-Tabelle entfernt werden soll) und verschiedene andere, globale Variablen.
Alle diese globalen Daten sind sorgfältig ausgelegt, um sich der für die Speicherung der Daten verwendeten Hardwarestruktur anzupassen. So werden zum Beispiel auf einem Prozessor mit 64-Byte-Cachespeicherzeilen die Daten in eine einzelne 64-Byte-Struktur gepackt. Dadurch wird gewährleistet, dass es beim Zugriff auf irgendwelche dieser Daten jeweils nur höchstens zu einem einzigen Cache-Fehlgriff kommen kann. Da ein Cache-Fehlgriff in einer Grössenordnung von einhundert Zyklen oder mehr auftreten kann und da die Interruptbehandlungsroutine zur Durchführung ihrer Aufgabe insgesamt nur ein paar hundert Zyklen benötigen sollte, stellt die Minimierung der Cache-Fehlgriffe eine absolute Notwendigkeit dar, um deren Auswirkung auf die Leistungsdatenerfassung zu minimieren.
Ausserdem ist bei einem Multiprozessor das Schreiben in eine Cachespeicherzeile, welche Daten enthält, die von mehreren Prozessoren gemeinsam genutzt werden, eine kostspielige Angelegenheit. Globale Daten werden sorgfältig auf den einzelnen Prozessoren kopiert, so dass jeder Prozessor seine eigen Kopie besitzt, wodurch die Notwendigkeit, in gemeinsam genutzte Cachespeicherzeilen zu schreiben, vermieden wird.
In einer alternativen Ausführungsform kann die zur Behandlung von Interrupts benötigte Zeit durch die Verwendung mehrerer Behandlungsroutinen verringert werden, wobei jede Behandlungsroutine für bestimmte Situationen optimiert ist. So prüft zum Beispiel in einem nachfolgend beschriebenen Ausführungsbeispiel mit mehreren Überlauf-Pufferspeichern die Interruptbehandlungsroutine zu Beginn, ob sie die Hash-Tabelle umgehen soll. In den meisten Fällen wird sich diese Prüfung als nicht zutreffend erweisen.
Es kann jedoch eine Version der Interruptbehandlungsroutine angefertigt werden, welche darauf verzichtet, das Flag zu prüfen, um zu sehen, ob sie die Hash-Tabelle umgehen sollte. Stattdessen nimmt die Behandlungsroutine an, dass sie auf die Hash-Tabelle zugreifen soll. In jenen Fällen, in denen das Flag verändert worden ist, welches anzeigt, ob die Hash-Tabelle umgangen werden soll oder nicht, kann ein Interrupt-Vektor auf Systemebene verändert werden, um auf die zuständige Interruptbehandlungsroutine zu zeigen. In dem üblichen Fall, in welchem die Hash-Tabelle nicht umgangen werden soll, wird damit sichergestellt, dass keine Prüfung zu erfolgen braucht, wodurch mehrere Prozessorzyklen eingespart werden können. Eine sorgfältige Analyse aller verschiedenen Flags und deren Einstellungen für Routinefälle, sowie die Verwendung von spezialisierten Versionen der für die Routinefälle eingesetzten Interruptbehandlungsroutine, kann zu einer bedeutenden Leistungssteigerung führen.
Es folgt nun eine genauere Beschreibung der Synchronisierung mit anderen Prozessen, welche erfolgt, während die in der Hash-Tabelle gespeicherten Daten bearbeitet werden.
Synchronisierung:
Die Synchronisierung des Zugriffs auf die Hash-Tabelle und den Überlauf-Pufferspeicher ist wie folgt geregelt. Erstens sind für jeden Prozessor eigene Hash-Tabellen 234–236 vorhanden; folglich brauchen sich die auf den verschiedenen Prozessoren laufenden Interruptbehandlungsroutinen 231-233 zum Zweck der Handhabung der Hash-Tabellen nicht untereinander zu synchronisieren. Gemeinsam genutzt wird von den Behandlungsroutinen jedoch der Überlauf-Pufferspeicher 238, und daher muss der Zugriff auf den Überlauf-Pufferspeicher wie nachfolgend beschrieben synchronisiert werden.
Ausserdem werden von den Systemkern-Gerätetreibern Prozeduren bereitgestellt, die es dem Dämon 261 auf Benutzerebene erlauben, sämtliche Abtastwerte aus den Tabellen und dem Überlauf-Pufferspeicher des Systemkerns in den Benutzer-Pufferspeicher 262 zu übernehmen, um so zu gewährleisten, dass der Dämon 261 über die aktuellen Daten verfügt. Jeweils eigene Routinen, genannt "flush_hash" und "flush_overflow" werden bereitgestellt, um Daten jeweils aus den Hash-Tabellen bzw. aus dem Überlauf-Pufferspeicher auszulesen. Diese Routinen müssen, wie weiter unten beschrieben, mit den Behandlungsroutinen 231–233 synchronisiert werden.
Hasch-Tabellensynchronisierung
Es gibt zwei Aktivitäten, die ihren Zugriff auf die Hash-Tabelle eines gegebenen Prozessors synchronisieren müssen: die Interruptbehandlungsroutine für diesen Prozessor und die "flush_hash"-Routine. Die Zeitsteuerung von möglichen Ereignissen, die synchronisiert werden müssen, ist in 5 dargestellt. Die globalen Variablen, welche von der Interruptbehandlungsroutine und von der "flush_hash"-Routine gemeinsam genutzt werden, sind in 6 gezeigt. Der Pseudocode für die Interruptbehandlungsroutine wird in 7 gezeigt, und der Pseudocode für die "flush_hash"-Routine wird in 8 angegeben.
Während eine Hash-Tabelle für einen bestimmten Prozessor gerade entleert wird, darf der Interruptbehandlungsroutine kein Zugriff auf diese Tabelle erlaubt werden. Daher speichert die Interruptbehandlungsroutine während dieser Zeit die Abtastwerte direkt in den Überlauf-Pufferspeicher 238. Um die Anzahl der Abtastwerte, die direkt in den Überlauf-Pufferspeicher 238 geschrieben werden, zu minimieren, wird die Hash-Tabelle datenblockweise entleert. Ein Abtastwert, dessen Index in einen Datenblock fällt, der gerade entleert wird, wird direkt in den Überlauf-Pufferspeicher geschrieben. Ein Abtastwert, dessen Datenblock jedoch nicht gerade entleert wird, wird, wie weiter oben beschrieben, in die Hash-Tabelle geschrieben.
Das "active_chunk"-Flag 315 und das "flush_chunk"-Flag 316 zeigen jeweils an, welche Datenblöcke gerade von der Interruptbehandlungsroutine und der "flush_hash"-Routine benutzt werden. Jedes Flag zeichnet den Namen des Datenblocks auf; ein Datenblock wird nach dem Index seines ersten Eintrags benannt. Der Wert –1 wird in dem "active_chunk"-Flag und dem "flush_chunk"-Flag verwendet, um anzuzeigen, dass kein Datenblock in Verwendung steht, weil z. B. der Datenblock inaktiv ist.
Es sei darauf hingewiesen, dass die Prozeduren zum Bestimmen eines nächsten freien Platzes zum Speichern der Abtastwerte in dem Überlauf-Pufferspeicher und zum Schreiben eines Eintrags in den freien Platz des Überlauf-Pufferspeichers weiter unten als Teil der Beschreibung der Synchroni sierung des Zugriffs auf den Überlauf-Pufferspeicher 238 beschrieben werden. Dort wird auch der Datentyp "slot_index" beschrieben werden.
Die Synchronisierung in der "flush-hash"-Routine ist eine heikle Angelegenheit, zum Teil auch deswegen, weil die Routine dazu bestimmt ist, in einem System bestehend aus einer Mehrzahl von Hochgeschwindigkeits-Prozessoren, verwendet zu werden, bei dem das Speichermodell nicht sequentiell konsistent ist, vgl. L. Laport, "How to make a multiprocessor computer that correctly executes multiprocess programs" (Anleitung zum Zusammenstellen eines Multiprozessor-Computers, welcher Multiprozess-Programme korrekt ausführt). IEEE Transactions on Computers C-28, (September 1979) S. 690–691.
Ein Speichermodell ist sequentiell inkonsistent, wenn die Reihenfolge des Ablaufs von Operationen nur unter bestimmten Bedingungen gewährleistet ist. Prozessoren können Befehle in einer ersten Reihenfolge ausgeben und ausführen, das Speicher-Subsystem kann jedoch Zugriffe in einer zweiten Reihenfolge (der sogenannten "Speicherreihenfolge" vollständig abarbeiten. Darüber hinaus ist die Speicherreihenfolge transitiv: wenn A vor B eintritt und B vor C eintritt, dann tritt A vor C ein. Die Reihenfolge, in welcher Operationen tatsächlich erfolgen, wird durch die Speicherreihenfolge gemäss den folgenden Zwangsbedingungen bestimmt.

1. Speicherzugriffsoperationen auf einen einzelnen Speicherort seitens eines einzelnen Prozessors erfolgen in der Reihenfolge, in welcher die Zugriffsbefehle von diesem Prozessor ausgegeben werden.
2. Speicherzugriffsoperationen auf verschiedene Speicherorte seitens eines einzelnen Prozessors können in jeder beliebigen Reihenfolge erfolgen, es sei denn, die Operationen sind durch einen "Speicherbarrierenbefehl" (MB) voneinander getrennt. In diesem Fall werden sämtliche Operationen, die sich vor dem Speicherbarrierenbefehl befinden, vor sämtlichen Operationen ausgeführt, die nach dem Speicherbarrierenbefehl erfolgen.
3. Wenn zwei Prozessoren auf denselben Speicherort zugreifen, wobei der eine eine Schreiboperation und der andere eine Leseoperation ausführt, und wenn weiterhin die Leseoperation den gerade geschriebenen Wert erkennt, so erfolgt die Leseoperation nach der Schreiboperation.

Es sei hier bemerkt, dass der Speicherbarrierenbefehl eine relativ lange Zeit zur Ausführung benötigt. Daher ist es wünschenswert, die Verwendung des Speicherbarrierenbefehls auf häufig verwendeten Ausführungspfaden möglichst gering zu halten.
Abhängig von einem bestimmten Pfad, der in der in 7 gezeigten Interruptbehandlungsroutine eingenommen wird, gibt es drei verschiedene Möglichkeiten zu beachten. Die Behandlungsroutine kann den Code beginnend bei Zeile 704, 707, oder den Zeilen 709–722 ausführen. Ein jeder dieser Fälle wird weiter unten der Reihe nach beschrieben.
Erstens, wenn die Behandlungsroutine den Code beginnend bei Zeile 704 ausführt, so braucht die Behandlungsroutine überhaupt nicht auf die Hash-Tabelle zuzugreifen. Die Abtastwerte werden direkt in den Überlauf-Pufferspeicher 238 ge schrieben, welcher, wie weiter unten beschrieben, synchronisiert wird, um ein Verlorengehen bzw. eine Doppeltzählung von Abtastwerten zu vermeiden. Es ist in diesem Fall möglich, dass die Behandlungsroutine bei Erreichen der Zeile 703 beschliesst, die Zeile 704 auszuführen, obwohl die Variable "flush_chunk[i]" von der (auf einem anderen Prozessor laufenden) "flush_hash"-Routine auf einen anderen Wert als c gesetzt worden ist.
Dazu kann es deswegen kommen, weil das Speicher-Subsystem 120 aus 1 nicht garantiert, dass der neue Wert der Variablen "flush_chunk[i]" sofort auf allen Prozessoren angezeigt wird. Dies führt nicht zu einem unkorrekten Verhalten; es bedeutet lediglich, dass einige Abtastwerte in den Überlauf-Pufferspeicher geschrieben werden, obwohl sie genauso gut hätten in der Hash-Tabelle gespeichert werden können. Das heisst, es kommt zwar zu einer geringfügigen Leistungsmiderung, die Korrektheit der Daten ist davon jedoch nicht betroffen.
Zweitens, wenn die Behandlungsroutine den Code in Zeile 707 ausführt, werden keine kostspieligen Synchronisationsoperationen durchgeührt. Wenn die Behandlungsroutine sich bei Zeile 707 befindet, hat sie einen passenden Eintrag in der Hash-Tabelle gefunden, was bedeutet, dass sie lediglich den Zählerstand für diesen Eintrag zu inkrementieren braucht. Hierbei ist allerdings zu beachten, dass es in diesem Fall möglich, wenn auch äusserst unwahrscheinlich ist, dass ein einzelner Abtastwert verlorengeht.
5 zeigt mögliche Zeitsteuerungen für Hash-Tabellenzugriffe. In 5 stellt die Linie 560 eine allgemeine Zeitleiste dar, welche von links nach rechts zunimmt, die Linie 570 gibt die Zeitsteuerung von Ereignissen einer Interruptbehandlungsroutine 531 eines Prozessors (cpu j) an, und die Linie 580 zeigt die Zeitsteuerung der Ereignisse der "flush_hash"-Routine eines anderen Prozessors (cpu i) 532.
Die Interruptbehandlungsroutine (cpu j) 531 führt mehrere Aktionen aus: sie liest das "flush_chunk"-Flag (Ereignis C 571); sie findet einen Treffer in der Hash-Tabelle auf; sie liest den Zählerstand für den passenden Eintrag in der Hash-Tabelle (Ereignis D 572); und sie schreibt den inkrementierten Zählerstand zurück in die Hash-Tabelle (Ereignis E 573).
Wenn die "flush_hash"-Routine nicht gerade gleichzeitig abläuft, um den Überlauf-Pufferspeicher 238 zu entleeren, so wird der inkrementierte Zählerstand korrekt zurückgeschrieben. Es ist jedoch möglich, dass obwohl die Interruptbehandlungsroutine das "active_chunk"-Flag 315 geprüft hat und erkannt hat, dass es für den benötigten Datenblock nicht gesetzt war, die "flush_hash"-Routine in der Praxis gerade dabei ist, diesen Datenblock gleichzeitig zu entleeren. In diesem seltenen Fall zeigt eine sorgfältige Analyse der Zeitsteuerung, wie sie weiter unten genauer beschrieben wird, dass es tatsächlich möglich ist, dass ein einzelner Abtastwert verloren geht, es kann jedoch andererseits nicht zu Doppelzählungen kommen.
In 5 finden die folgenden Ereignisse in Bezug auf die "flush_hash"-Routine statt. Das "flush_chunk"-Flag 316 wird für den Datenblock gesetzt, welcher als nächstes zu entleeren ist (Ereignis A 561). Dann kopiert die Routine den von der Interruptbehandlungsroutine verwendeten Hash-Tabellen eintrag in den Benutzer-Pufferspeicher (Ereignis G 583). Als nächstes setzt die Routine den Eintrag in der Hash-Tabelle auf Null (Ereignis H 584) und zeigt die Fertigstellung an, indem sie das "flush_chunk"-Flag 316 freigibt (Ereignis 585).
In 5 ist die Zeitsteuerung für zwei weitere Ereignisse dargestellt: die Zeit, zu welcher der aktualisierte Wert des "flush_chunk"-Flag mit Sicherheit alle anderen Prozessoren erreicht hat (Ereignis B 582), und die Zeit, zu welcher der von der Interruptbehandlungsroutine in die Hash-Tabelle zurückgeschriebene, inkrementierte Zählerstand mit Sicherheit überall angekommen ist (Ereignis F 574). Hierbei ist zu beachten, dass diese Zeiten von einer spezifischen Prozessorimplementation abhängig sein können und sich nicht durch die Architektur-Spezifikationen vorbestimmen lassen.
Wenn das Ereignis E 573 (in der Speicherreihenfolge) vor dem Ereignis G 583 eintritt, dann wird zum Zeitpunkt des Ereignisses G 583 der inkrementierte Zählerstand in den Benutzer-Pufferspeicher kopiert und der Zählerstand zum Zeitpunkt des Ereignisses H 584 auf Null gesetzt. In diesem Fall wird der Abtastwert genau einmal gezählt. Dies ist selten der Fall.
Wenn das Ereignis E 573 nach dem Ereignis H 584 eintritt, wird der inkrementierte Zählerstand in die Hash-Tabelle zurückgeschrieben, nachdem der Zählerstand in dem Eintrag auf Null gesetzt worden ist. Dies würde dazu führen, dass die durch den ursprünglichen Zählerstand in diesem Eintrag dargestellten Abtastwerte zweimal gezählt würden, einmal indem sie zum Zeitpunkt des Ereignisses G in den Benutzer-Pufferspeicher kopiert werden, und ein zweites Mal dann, wenn dieser Eintrag das nächste Mal aus der Hash-Tabelle entfernt bzw. entleert wird. Dies ist insofern nicht annehmbar, als ein einzelner Hash-Tabelleneintrag mengenmässig beträchtlich zu Buche schlagen kann und zahlreiche Abtastwerte darstellen kann.
Eine Doppelzählung kann nicht erfolgen, solange das Ereignis E 573 vor dem Ereignis H 584 eintritt. Dies wird durch die weiter unten für die folgenden Variablen angegebenen Zwangsbestimmungen gewährleistet.
Als "max_prop" sei die maximale Zeitdauer bezeichnet, die ein gespeicherter Wert benötigen kann, um sich auf alle Prozessoren auszubreiten. Als "max_intr" sei die maximale Zeitdauer bezeichnet, welche die Interrupt-Routine benötigt, wenn sie die Zeile 707 aus 7 ausführt. Als "min_flush" sei die Mindestzeit bezeichnet, die für einen gegebenen Eintrag von dem Ereignis A (561) zu dem Ereignis H (484) verstreicht (d. h. die Mindestzeit von dem Zeitpunkt, da das "flush_chunk"-Flag 316 gesetzt wird bis zu jenem Zeitpunkt, da das Flag 316 von der "flush_hash"-Routine wieder aufgehoben wird).
Mit der folgenden Zwangsbedingung wird sichergestellt, dass das Ereignis E vor dem Ereignis H eintritt: (max_intr + (2*max_prop)) < min_flush.
Zur Bestimmung von max_prop und max_intr kann die Zeitsteuerung in einer spezifischen Prozessorimplementierung gemessen werden. Dann kann die Grösse des Datenblocks entsprechend gross gewählt werden, um zu gewährleisten, dass min_flush gross genug ist.
Drittens, wenn die Behandlungsroutine die Zeilen 709–722 ausführt, muss sie einen Eintrag von der Hash-Tabelle in den Überlauf-Pufferspeicher verschieben, und anschliessend einen neuen Eintrag mit dem Zählerstand 1 in die Hash-Tabelle schreiben.
Um einen Verlust oder eine Doppelzählung des von der Hash-Tabelle in den Überlauf-Pufferspeicher verschobenen Eintrags zu vermeiden, kommt eine sorgfältige Synchronisierung mit den beiden Flags (active_chunk[i] und flush_chunk[i]) unter Verwendung von bis zu drei Speicherbarrierenoperationen zur Anwendung. Diese Synchronisierung ist zwar relativ kostenaufwendig, sie kommt jedoch nur dann zum Einsatz, wenn ein Fehlgriff in der Hash-Tabelle erfolgt, was relativ selten der Fall ist.
Die wichtigste Eigenschaft dieses Codes besteht darin, dass die Zeilen 719 und 720 in einem einander wechselseitig ausschliessenden Verhältnis mit der Zeile 707 stehen. Bei diesem Algorithmus handelt es sich um eine Variante der für die Verwendung in Speicherbarrierebefehlen angepassten Standardtechniken des wechselseitigen Ausschlusses. Diese Technik erzwingt die Reihung von Operationen und gewährleistet, dass die Interruptbehandlungsroutine nicht auf eine Sperre wartet.
Anstatt zu warten, bis die "flush_hash"-Routine mit dem gewünschten Datenblock fertig ist, umgeht die Interruptbehandlungsroutine einfach die Hash-Tabelle auf den Zeilen 714–716, wenn der gewünschte Datenblock nicht verfügbar ist. Auch in dem äusserst unwahrscheinlichen Fall, dass der Überlauf-Pufferspeicher voll sein sollte, kehrt die Interruptbehandlungsroutine einfach an den Ausgangspunkt zurück, wobei der Abtastwert ausgeschieden wird. Als Vorteil dabei ergibt sich, dass in diesem Fall keine Abtastwerte verloren gehen oder doppelt gezählt werden, wenn die Behandlungsroutine die Zeilen 709–722 ausführt.
Die Nettoauswirkung dieses Ansatzes besteht darin, dass in dem üblichen Fall eines Treffers in der Hash-Tabelle die Behandlungsroutine keine kostenintensiven Synchronisierungsoperationen ausführt, dass dafür jedoch in sehr seltenen Fällen ein Abtastwert verloren gehen kann.
Es sei hierbei darauf hingewiesen, dass die Zeilen 710, 714 und 718 optimiert werden können; das in Zeile 711 erfolgende Ermitteln eines freien Platzes in dem Überlauf-Pufferspeicher setzt das Anfordern und Wiederfreigeben einer Sperre voraus. Zum Anfordern der Sperre, ebenso wie das Wiederfreigeben derselben, macht eine Speicherbarriere erforderlich, wodurch die Speicherbarriere bei Zeile 710 entfernt werden kann. Darüber hinaus ist es möglich, wenn die Wiederfreigabe der Sperre an einen Punkt verschoben wird, der nach der in Zeile 713 erfolgenden, bedingten Prüfung gelegen ist (d. h. die Freigabe der Sperre in den Zeilen 714 und 718 erfolgt), die Speicherbarrieren in den Zeilen 714 und 718 ebenfalls zu entfernen.
Überlauf-Pufferspeichersynchronisierung
In einer bevorzugten Implementation ist der Überlauf-Pufferspeicher 238 in der Tat in zwei Abschnitte aufgeteilt, wodurch es möglich ist, dass ein Abschnitt entleert wird, während auf einen anderen Abschnitt von einer Behandlungsroutine zugegriffen wird. Diese Technik wird manchmal auch als "doppelte Pufferung" bezeichnet. Ausserdem wird die Sperre 239 nur während der Zeit auf dem Überlauf-Puffer speicher 238 gehalten, während der in den. Puffer weisende Zeiger verändert werden und nicht während der gesamten Zeit, während der Einträge in diesen geschrieben werden. Dadurch wird die Effizienz insofern erhöht, als es Behandlungsroutinen erlaubt wird, Einträge parallel zueinander in denselben Überlaufpufferspeicher zu schreiben.
Der Klarheit halber wurde die weiter oben vorgenommene Beschreibung des Überlauf-Pufferspeichers 238 vereinfacht dargestellt, als ob es sich dabei um einen einzelnen Puffer handeln würde, wobei ein freier Platz durch einen Wert vom Typ slot_index identifiziert wird. Hier werden Einzelheiten darüber gegeben, wie der Puffer und ein slot_index dargestellt werden.
Es gibt zwei Pufferspeicher. Ein Index (slot_index) in die Puffer besteht aus einer Puffer-ID (entweder 0 oder 1) und dem Index eines freien Platzes in dem betreffenden Puffer. Die von den Behandlungsroutinen und der "flush_overflow'-Routine gemeinsam genutzten, globalen Variablen werden in 9 gezeigt; die Prozeduren, die von den Behandlungsroutinen benutzt werden, um den nächsten freien Platz zu ermitteln und einen Eintrag in den Überlauf-Pufferspeicher zu schreiben, werden in den 10 und 11. gezeigt; und die "flush_overflow"-Routine wird in 12 gezeigt.
Die "flush_overflow"-Routine entleert einen einzelnen Pufferspeicher. Wenn ein voller Speicher darauf wartet, ausgelesen zu werden, wird er entleert; ansonsten wird der aktuelle, zum Teil gefüllte Pufferspeicher entleert, während Überlaufdaten in den anderen Pufferspeicher geschrieben werden.
Eine einzige Sperre [overflow_lock (Überlaufsperre)] wird dazu verwendet, um den Zugriff auf die Variablen aus 9 zu synchronisieren und um den Puffer zu verwalten (index, completed, current overflow, und full overflow). Alle Aktualisierungen dieser Variablen werden bei gesetzter Überlaufsperre durchgeführt. Für den Pufferspeicher i ist "index[i]" der Index des als nächstes zu beschreibenden, freien Platzes.
Während des Schreibens von Einträgen in den Überlauf-Pufferspeicher wird die Sperre nicht gehalten; stattdessen wird durch das Inkrementieren von "index[i]" ein freier Platz in dem Pufferspeicher i reserviert. Nur jener Prozessor, welcher den freien Platz reserviert hat, ist berechtigt, in diesen zu schreiben. Wenn der Prozessor mit dem Schreiben in den freien Platz fertig ist, so inkrementiert er "completed[i]", wie unter Bezugnahme auf 11 beschrieben. Somit können freie Plätze in beliebiger Reihenfolge beschrieben werden (obwohl sie in einer spezifischen Reihenfolge reserviert sind).
Die Solange-Schleife in der "flush_overflow"-Routine wartet, bis "completed[i]" gleich "index[i]" ist. Das bedeutet, dass alle Schreiboperationen in alle freien Plätze, die reserviert waren, abgeschlossen worden sind. Es sei hier angemerkt, dass "index[full_overflow]" sich nicht ändern kann, während sich die "flush_overflow"-Routine in der Solange-Schleife befindet, da für einen vollen Überlauf-Pufferspeicher keine freien Plätze reserviert werden. Es sei des weiteren auch darauf hingewiesen, dass "completed[full_overflow]" monoton inkrementiert wird; da Leseoperationen atomar sind, ist es gerechtfertigt, "completed[full_overflow]" bei nicht gehaltener Sperre zu le sen, da zu dem Zeitpunkt, zu dem ein Wert angetroffen wird, welcher gleich "index[full_overflow]" ist, alle Schreiboperationen in reservierte, freie Plätze abgeschlossen worden sein müssen.
Die Speicherbarriere nach der Solange-Schleife in Zeile 805 aus 8 wird benötigt, um sicherzustellen, dass die Speicheroperationen, die an dem Kopiervorgang des vollen Überlauf-Pufferspeichers in den Benutzer-Pufferspeicher beteiligt sind, erst nach der Prüfung stattfinden, im Zuge derer "completed[full_overflow]" mit "index[full_overflow]" verglichen wird, oder anders ausgedrückt, nachdem die Schreiboperationen in den Pufferspeicher tatsächlich abgeschlossen worden sind.
Bei der oben beschriebenen Technik entleeren alle Prozessoren ihre Daten in einen gemeinsamen Pufferspeicher, was für jeden Entleerungsvorgang einen gewissen Grad an Koordinierung zwischen den Prozessoren erforderlich macht. Tatsächlich ist ein Paar von Überlauf-Pufferspeichern vorhanden, das es ermöglicht, die zu entleerenden Daten in einen Pufferspeicher fliessen zu lassen, wenn der andere voll ist, jedoch erst in den Benutzerbereich entleert werden muss. Durch weitere Synchronisierungsverfahren, basierend auf einer sorgfältigen Analyse der Zeitsteuerung von Ereignissen, wird eine sachgemässe Synchronisierung des Zugriffs auf die Hash-Tabellen gewährleistet.
Prozessorgebundene, lokale Überlauf-Pufferspeicher
In einer alternativen Ausführungsform kann das oben beschriebene Verfahren mit prozessorgebundenen Hash-Tabellen und einem einzigen, gemeinsam genutzten Überlauf-Pufferspeicher durch einen zusätzlichen, kleinen Überlauf-Puffer speicher für jeden Prozessor erweitert werden. Bei diesem Verfahren prüft eine Interruptbehandlungsroutine, die in einen Überlauf-Pufferspeicher schreiben möchte, zuallererst ihren lokalen Überlauf-Pufferspeicher. Wenn dieser Pufferspeicher nicht voll ist, so schreibt sie einfach in diesen Pufferspeicher. Wenn dieser Pufferspeicher voll ist, so nimmt sie die Sperre für den gemeinsam genutzten Überlauf-Pufferspeicher für sich in Anspruch und kopiert ihren gesamten lokalen Pufferinhalt in den gemeinsam genutzten Pufferspeicher. Dadurch wird die Häufigkeit, mit der die Sperre in Anspruch genommen wird, und auch die Häufigkeit, mit der gemeinsam genutzte Cache-Speicherzeilen beschrieben werden, verringert, was im Fall von Multiprozessoren zu Leistungsverbesserungen führt.
Mehrfach vorhandene Überlauf-Pufferspeicher
In einer alternativen Ausführungsform kann eine andere Synchronisierungstechnik zum Einsatz kommen, welche es erlaubt, die Kosten der Hash-Tabellensynchronisierung und des Zugriffs auf den Überlauf-Pufferspeicher zu verringern, und bei der im Gegenzug dafür zusätzliche Überlauf-Pufferspeicher verwendet werden, z. B. zwei Pufferspeicher pro Prozessor anstatt eines einzigen, von allen Prozessoren gemeinsam genutzten Doppelpuffers.
Bei dieser Technik "besitzt" jeder Prozessor eine private Hash-Tabelle (wie oben) und dazu ein Paar privater (doppelter) Überlauf-Pufferspeicher. Das Wort "besitzen" bedeutet in diesem Fall, dass – mit einer Ausnahme – alle an dem Zustand von aktiven Pufferspeichern und Hash-Tabellen vorgenommenen Modifikationen jeweils von dem betreffenden Prozessor vorgenommen werden, wodurch zahlreiche Operationen zur Speichersynchronisierung eliminiert werden können, wel che bei der weiter oben beschriebenen Technik mit nur einem einzigen doppelten Pufferspeicher durchzuführen sind.
Es sind hier zwei grundlegende Änderungen im Vergleich zu der ersten Technik zu nennen. Erstens, während der Entleervorgänge der Hash-Tabelle in den Benutzerbereich werden an den aktiven Überlauf-Pufferspeicher unter Umgehung der Hash-Tabelle Leistungszählerereignisse angehängt. Dadurch erübrigt sich der Synchronisierungsvorgang, der ansonsten nötig ist, um sicherzustellen, dass die Hash-Tabelle nicht während einer Entleeroperation modifiziert wird. Wie bei der erstgenannten Technik kann auch hier die Hash-Tabelle datenblockweise entleert werden, wodurch die Häufigkeit verringert wird, mit der Ereignisse direkt an den Überlauf-Pufferspeicher angehängt werden müssen.
Zweitens, jeder Prozessor verfügt über ein privates Paar von Überlauf-Pufferspeichern, wodurch sich der Synchronisierungsvorgang erübrigt, der ansonsten erforderlich ist, um einen einzelnen, aktiven Überlauf-Pufferspeicher durch alle Prozessoren gemeinsam zu nutzen.

Der folgende Datenzustand wird auf jedem Prozessor gehalten:

(A) buffer overflow[ncpus] [2]	Ein Paar Überlauf-Pufferspeicher pro Prozessor
(B) int: index[ncpus] [2]	Index des nächsten zu beschreibenden freien Platzes
(C) int: active[ncpus]	Index des aktiven Überlauf-Pufferspeichers
(D) bool: allow_flip[ncpus]	Flag: Ist es erlaubt, die Pufferspeicher zu durchblättern?
(E) bool: bypass_hash[ncpus]	Flag: Hash-Tabelle umgehen?

Hasch-Tabellensynchronisierung
Es gibt zwei Aktivitäten, welche auf die Hash-Tabelle für einen bestimmten Prozessor zugreifen:

1) Die Interruptbehandlungsroutine, welche neue Abtastwerte in der Hash-Tabelle abspeichert, und
2) Die "flush_hash"-Routine, welche die Hash-Tabelle in den Benutzerbereich kopiert.

In dem in 13 gezeigten Pseudocode für die Behandlung von Überlauf-Pufferspeicherereignissen während Interrupts wird die "bypass hash"-Routine zur Steuerung des Zugriffs auf die Hash-Tabelle verwendet. Die Zeilen 1301–1303 zeigen, dass wenn diese Variable auf "wahr" gesetzt wird, die Interruptbehandlungsroutine die Hash-Tabelle zur Gänze überspringt und den neuen Abtastwert direkt in den Überlauf-Pufferspeicher schreibt.
Die Zeilen 1305–1310 zeigen den anderen Pfad durch die Interruptbehandlungsroutine. Wenn der neue Abtastwert mit einem der Einträge in der Hash-Tabelle (Zeilen 1305–1306) übereinstimmt, dann inkrementiert die Behandlungsroutine einfach den dem übereinstimmenden Eintrag zugeordneten Zählerstand. Andernfalls (Zeilen 1308–1310) wählt die Behandlungsroutine einen der bestehenden Einträge zur Entleerung aus. Dieser Eintrag wird aus der Hash-Tabelle entfernt und in den Überlauf-Pufferspeicher geschrieben. Der neue Ab tastwert wird in den freien Platz in der Hash-Tabelle geschrieben.
Der Pseudocode für die "flush_hash"-Routine wird in 14 gezeigt. Für jeden Prozess setzt die Routine das "bypass_hash[cpu]"-Flag auf wahr (Zeilen 1404 und 1408), kopiert die Hash-Tabelle in den Benutzerbereich, und setzt daraufhin das "bypass hash[cpu]"-Flag wieder auf falsch. Zur Gewährleistung einer korrekten Synchronisierung achtet die "flush_hash"-Routine sorgfältig darauf, die Veränderungen an "bypass_hash[cpu]" auf dem mit "cpu" gekennzeichneten Prozessor auszuführen.
Wenn es sich bei dem Prozessor, auf welchem die "flush_hash"-Routine läuft, um denselben Prozessor handelt, dessen Hash-Tabelle kopiert wird (Zeilen 1403–1406), so führt die Routine das Setzen und Wiederaufheben des "bypass_hash[cpu]"-Flags mittels lokaler Operationen durch. Andernfalls verwendet die "flush_hash"-Routine Interprozessor-Interrupts, um zu bewirken, dass die Veränderungen an "bypass hash[cpu]" auf "cpu" ausgeführt werden.
Die Synchronisierung zwischen Interruptbehandlungsroutine und "flush_hash"-Routine erfolgt korrekt, weil "bypass hash[cpu]" jeweils nur auf dem Prozessor mit der Nummer "cpu" gelesen und beschrieben wird. Die Interprozessor-Interrupts sind entsprechend eingestellt, um auf derselben Interrupt-Prioritätsebene abzulaufen wie die Interruptbehandlungsroutine für den Leistungszählerüberlauf, wodurch gewährleistet wird, dass sie in Bezug aufeinander atomar ausgeführt werden. Es können anstatt der Interprozessor-Interrupts auch andere Übertragungsmechanismen, wie zum Beispiel das Senden einer Nachricht, verwendet werden, vorausgesetzt es bleibt dabei immer derselbe Grad an Atomizität gewährleistet.
Überlauf-Pufferspeichersynchronisierung
Es gibt zwei Aktivitäten, die das einem bestimmten Prozessor zugeordnete Überlauf-Pufferspeicherpaar benutzen. Erstens, die Interruptbehandlungsroutine, welche manchmal Einträge in die Überlauf-Pufferspeicher schreibt. Zweitens, die "flush_overflow"-Routine, welche periodisch den Inhalt der Überlauf-Pufferspeicher in den Benutzerbereich kopiert. Diese beiden Aktivitäten werden dadurch synchronisiert, indem jeweils einer der Pufferspeicher als der "aktive" Pufferspeicher markiert wird. Die Interruptbehandlungsroutine darf nur in den "aktiven" Pufferspeicher schreiben, und die "flush_overflow"-Routine darf nur von dem inaktiven Pufferspeicher lesen.
Ist der aktive Pufferspeicher voll, so versucht die Interruptbehandlungsroutine die Pufferspeicher zu wechseln (zu vertauschen), indem sie den bislang aktiven Pufferspeicher als inaktiven und den bislang inaktiven Pufferspeicher als aktiven Pufferspeicher markiert. Das "allow_flip[cpu]"-Flag wird verwendet, um zu verhindern, dass ein solcher Wechsel stattfindet, während die "flush_overflow"-Routine gerade dabei ist, den bislang inaktiven Pufferspeicher in den Benutzerbereich zu kopieren.
Eine Routine zum Hinzufügen eines Eintrags zu den Überlauf-Pufferspeichern für einen bestimmten Prozessor wird in 15 gezeigt. Ist der aktive Pufferspeicher nicht voll (Zeile 1502), so hängt die Routine den Abtastwert einfach an den aktiven Pufferspeicher an. Ist der aktive Puffer speicher voll, so versucht die Routine, die Pufferspeicher zu wechseln (zu vertauschen).
Die Routine führt vorerst eine Überprüfung durch, um zu ermitteln, ob ein Vertauschen möglich ist oder nicht (Zeile 1505). Ist ein Vertauschen erlaubt, so vertauscht sie die Pufferspeicher und bereitet den neuen aktiven Pufferspeicher auf den Beschreibvorgang vor, indem sie alle Abtastwerte aus dem neuen aktiven Puffer entfernt (Zeile 1508). Nachdem die Pufferspeicher vertauscht worden sind, veranlasst die Routine den Dämon auf Benutzerebene, den vollen, inaktiven Speicher auszulesen (Zeile 1507). Der neue Abtastwert wird dem neuen, aktiven Pufferspeicher hinzugefügt. Ist ein Vertauschen nicht erlaubt, so entfernt die Routine den neuen Abtastwert und springt zurück (Zeile 1511).
Die "write_to_overflow"-Routine entfernt Abtastwerte in zwei Fällen. Im ersten Fall werden nach einem Vertauschvorgang sämtliche in dem neuen aktiven Puffer befindlichen, ungelesenen Abtastwerte entfernt (Zeile 1505). Es ist äusserst unwahrscheinlich, dass tatsächlich irgendwelche Abtastwerte entfernt werden, da diese Abtastwerte seit dem Zeitpunkt des letzten Vertauschvorgangs der "flush_overflow"-Routine zum Auslesen zur Verfügung gestanden sind und da solche Vertauschvorgänge nur sehr selten durchgeführt werden.
Der zweite Fall ist dann gegeben, wenn der aktive Pufferspeicher voll ist und ein Vertauschen der Speicher nicht erlaubt ist. Auch hier ist es äusserst unwahrscheinlich, dass dieser Fall tatsächlich eintritt. Ein Vertauschen der Speicher ist nämlich nur dann nicht erlaubt, wenn die "flush_overflow"-Routine gerade dabei ist, den inaktiven Pufferspeicher auszulesen. Der inaktive Pufferspeicher war bereits zum Zeitpunkt des zuletzt erfolgten Vertauschens der Speicher bereit, ausgelesen zu werden, und da solche Vertauschvorgänge in dem vorliegenden System nur sehr selten vorkommen, ist es unwahrscheinlich, dass die "flush_overflow"-Routine immer noch mit dem Herauskopieren der Daten aus dem inaktiven Pufferspeicher beschäftigt ist. Wenn in den beiden vorangegangenen Fällen Abtastwerte entfernt werden, so ist dies ein Anzeichen dafür, dass die "flush_overflow"-Routine nicht rasch genug von dem Dämon auf Benutzerebene in Reaktion auf das Vollwerden eines Überlauf-Pufferspeichers aufgerufen wird.
Der Pseudocode für die "flush_overflow"-Routine wird in 16 gezeigt. Diese Routine kopiert den inaktiven Pufferspeicher für einen bestimmten Prozessor in den Benutzerbereich. Die Routine benützt das "allow_flip[cpu]"-Flag, um die "write_to_overflow"-Routine daran zu hindern, auf den inaktiven Pufferspeicher zuzugreifen, während dieser gerade in den Benutzerbereich kopiert wird. Wie oben bei der "flush_hash"-Routine beschrieben, werden auch hier Interprozessor-Interrupts benutzt, um zu gewährleisten, dass alle Zugriffe auf "allow_flip[cpu]" auf dem mit der Nummer "cpu" versehenen Prozessor erfolgen und somit korrekt synchronisiert sind.
Erfasste Daten
Je nach genauer Implementierung der Leistungszähler können Programmschrittzählerwerte auf ausgewählte Befehle hin abgetastet werden. Darüber hinaus können für Speicherzugriffe (Lade- und Speichervorgänge) und Sprungbefehle mit Operan den, welche Standardregister spezifizieren, auch Basisadressen erfasst werden.
Das hier beschriebene Leistungsüberwachungssystem ist in der Lage, Leistungsdaten für zahlreiche Aspekte des Betriebs eines Computersystems, unter anderem betreffend die Systemkernsoftware, die Eingabe-/Ausgabegerätetreiber, die Anwendungsprogramme, sowie die gemeinsam genutzten Bibliotheken zu erfassen. Dies wird durch das mit sehr hoher Frequenz erfolgende Aussenden und Verarbeiten von Abtast-Interrupts erreicht, ohne dass dadurch der normale Betrieb des Systems in übermässiger Weise beeinträchtigt wird.
Für einschlägig gebildete Fachleute ist leicht ersichtlich, dass verschieden Abänderungen an der vorliegenden Erfindung vorgenommen werden können, ohne dass dadurch vom Umfang der Erfindung, wie er unter Bezugnahme auf die beiliegenden Ansprüche definiert ist, abgegangen wird.

Claims

Vorrichtung (200) zum Erfassen von Leistungsdaten in einem Computersystem (100) mit einer Mehrzahl von Prozessoren (111, 121...223) zum gleichzeitigen Ausführung von Befehlen eines Programms, wobei die Vorrichtung folgendes umfaßt: eine Mehrzahl von mit jedem Prozessor verbundenen Leistungszählern (201) zum Abspeichern von Leistungsdaten, die von jedem Prozessor während des Ausführens der Befehle generiert werden; eine auf jedem Prozessor ausgeführte Interruptbehandlungsroutine (231...233) zum Abtasten der Leistungsdaten des Prozessors in Reaktion auf Interrupts (251...253); einen ersten Speicher mit einer Hash-Tabelle (234...236, 300), welche jeder Interruptbehandlungsroutine zugeordnet ist; wobei eine jede Hash-Tabelle zum Abspeichern der Leistungsdaten dient, die von der auf einem jeweiligen Prozessor ausgeführten Interruptbehandlungsroutine abgetastet werden; einen zweiten Speicher mit einem Überlauf-Pufferspeicher (238), wobei der Überlauf-Pufferspeicher zum Abspeichern von Leistungsdaten dient, wenn Teile der Hash-Tabellen voll werden bzw. wenn auf diese nicht zugegriffen werden kann; einen dritten Speicher mit einem Benutzer-Pufferspeicher (262); und eine Einrichtung (261) zum periodischen Entleeren der Leistungsdaten aus den Hash-Tabellen (234...236) und dem Überlauf-Pufferspeicher (238) in den Benutzer-Pufferspeicher (262).
Vorrichtung nach Anspruch 1, wobei eine jede Hash-Tabelle (300) des ersten Speichers als mehrwegiger Cache mit teilassoziativer Abbildung organisiert ist.
Vorrichtung nach Anspruch 2, wobei ein jeder mehrwegige Cache mit teilassoziativer Abbildung eine Mehrzahl von Datenblöcken ("chunks") (301...303) umfaßt und wobei ein jeder Datenblock eine Datenübertragungseinheit zwischen dem ersten und dem dritten Speicher darstellt.
Vorrichtung nach Anspruch 3, wobei jeder Datenblock (301...303) eine Mehrzahl von Zeilen (311...314) umfaßt und wobei jeder Datenblock einem "active_chunk"-Flag (315) zugeordnet ist, um anzuzeigen, wenn der entsprechende Datenblock inaktiv ist, und einem "flush_chunk"-Flag (316), um anzuzeigen, wenn der entsprechende Datenblock gerade in den Benutzer-Pufferspeicher (262) entleert wird.
Vorrichtung nach Anspruch 4, wobei eine jede Zeile (311...314) eine Mehrzahl von Einträgen (320) umfaßt und ein jeder Eintrag eine Mehrzahl von Feldern (321...324) zum Abspeichern der Leistungsdaten beinhaltet.
Vorrichtung nach Anspruch 5, wobei die Mehrzahl von Feldern (321...324) eines jeden Eintrags folgendes umfaßt: eine Prozeßkennzeichnung (321); einen Programmzähler (322); eine Prozessorereigniskennzeichnung (323); und einen Prozessorereigniszähler (324).
Vorrichtung nach Anspruch 6, welche weiterhin folgendes umfaßt: eine Einrichtung (231...233) zum Generieren eines Hash-Indexes aus der Prozeßkennzeichnung, dem Programmzähler und der Prozessorereigniskennzeichnung; den Hash-Index zum Prüfen der Zeilen der einem bestimmten Prozessor zugeordneten Hash-Tabelle (300) zum Zweck der Generierung eines Treffer- bzw. Fehlgriffsignals.
Vorrichtung nach Anspruch 7, welche weiterhin folgendes umfaßt: eine Einrichtung (231...233) zum Befördern (450) von Leistungsdaten, die bei einem aktuellen, mittels eines aus der Hash-Tabelle (300) entnommenen Hash-Indexes indizierten Eintrag (320) gespeichert sind, zu dem Überlauf-Pufferspeicher (238) in Reaktion auf das Fehlgriffsignal, und zum Überschreiben (460) des aktuellen Eintrags mit den von der Interruptbehandlungsroutine abgetasteten Leistungsdaten; und eine Einrichtung (231...233) zum Inkrementieren (420) des Prozessorereigniszählers, der bei dem aktuellen Eintrag gespeichert wird, der mittels des aktuellen Hash-Indexes in Reaktion auf das Treffersignal indiziert wird.
Vorrichtung nach Anspruch 6, welche weiterhin eine Einrichtung (231...233) zum Komprimieren der Leistungsdaten in die Einträge der Cachespeicherzeilen (311...314) umfaßt.
Vorrichtung nach Anspruch 1, wobei der Überlauf-Pufferspeicher (238) des zweiten Speichers einen ersten und einen zweiten Puffer beinhaltet, die als Doppelpuffer organisiert sind, und wobei ein jeder Puffer eine Mehrzahl freier Plätze zum Abspeichern der Leistungsdaten aus den Einträgen der Hash-Tabellen (300) beinhaltet.
Vorrichtung nach Anspruch 10, wobei der Überlauf-Pufferspeicher weiterhin eine Einrichtung (231...233) zum Auslesen der Leistungsdaten aus dem ersten Pufferspeicher und zum gleichzeitigen Schreiben der Leistungsdaten in den zweiten Pufferspeicher umfaßt.
Vorrichtung nach Anspruch 11, wobei der Überlauf-Pufferspeicher (238) weiterhin in mehrere Doppelpuffer unterteilt ist, wobei für einen jeden Prozessor (221...223) jeweils ein solcher vorhanden ist.
Vorrichtung nach Anspruch 1, wobei das Programm Anwendungs-, Betriebssystem-, und gemeinsam benutzte Bibliotheksprogrammkomponenten beinhaltet und weiterhin eine Einrichtung (221...223) zum gleichzeitigen Erfassen der Leistungsdaten der Anwendungs-, Betriebssystem-, und gemeinsam benutzten Bibliotheksprogrammkomponenten umfaßt.
Computerbetriebenes Verfahren zum Erfassen von Leistungsdaten in einem Computersystems (100) mit einer Mehrzahl von Prozessoren (111, 221...223), wobei die Mehrzahl von Prozessoren in Parallelbetrieb zueinander Befehle eines Programms ausführen, und wobei das Verfahren folgendes umfaßt: das in einer Mehrzahl von Gruppen von Leistungszählern (201) erfolgende Abspeichern von Leistungsdaten, welche von jedem Prozessor generiert werden, wobei an einen jeden Prozessor jeweils eine Gruppe von Leistungszählern gekoppelt ist; das Abtasten der in den Gruppen von Leistungszählern gespeicherten Leistungsdaten in Reaktion auf Interrupts (251...253); das Abspeichern der abgetasteten Leistungsdaten in einer Mehrzahl von Hash-Tabellen (234...236, 300) eines ersten Speichers, wobei für einen jeden Prozessor eine Hash-Tabelle existiert; das Abspeichern der abgetasteten Leistungsdaten in einem Überlauf-Pufferspeicher (238) eines zweiten Speichers, wenn Teile der Hash-Tabelle voll werden bzw. auf diese nicht zugegriffen werden kann; und das periodische Entleeren der abgetasteten Leistungsdaten aus den Hash-Tabellen und dem Überlauf-Pufferspeicher in einen in einem dritten Speichers vorhandenen Benutzer-Pufferspeicher (262).
Verfahren nach Anspruch 14, welches weiterhin die folgenden Schritte umfaßt: das Anordnen einer jeden Hash-Tabelle (300) zu einem mehrwegigen Cache mit teilassoziativer Abbildung, welcher eine Mehrzahl von Datenblöcken (301...303) umfaßt, wobei ein jeder Datenblock eine Datenübertragungseinheit zwischen dem ersten und dem dritten Speicher darstellt, und das Verwenden eines "active_chunk"-Flags (315), um anzuzeigen, wenn ein entsprechender Datenblock ("chunk") inaktiv ist, und eines "flush_chunk"-Flags (316), um anzuzeigen, wenn ein entsprechender Datenblock gerade in den Benutzer-Pufferspeicher (262) entleert wird.
Verfahren nach Anspruch 15, welches weiterhin die folgenden Schritte umfaßt: das Generieren eines Hash-Indexes aus einem Prozeßkennzeichnungsfeld (321), einem Programmzählerfeld (322) und einem-Prozessorereigniskennzeichnungsfeld (323) der abgetasteten Leistungsdaten; und das Verwenden des generierten Hash-Indexes zum Zweck der Prüfung der mit einem bestimmten Prozessor (221...223) assoziierten Hash-Tabelle (300), um ein Treffer- bzw. Fehlgriffsignal zu erzeugen.
Verfahren nach Anspruch 16, welches weiterhin die folgenden Schritte umfaßt: das Befördern (450) von Leistungsdaten, die bei einem mittels des Hash-Indexes indizierten, aktuellen Eintrag (320) der Hash-Tabelle (300) gespeichert sind, zu dem Überlauf-Pufferspeicher (238) in Reaktion auf ein Fehlgriffsignal, und das Überschreiben (460) des aktuellen Eintrags mit den abgetasteten Leistungsdaten; und das Inkrementieren (420) des bei dem aktuellen Eintrag gespeicherten Prozessorereigniszählerfeldes (324) in Reaktion auf ein Treffersignal.