DE112011101759B4

DE112011101759B4 - Sampling von Leerlauftransitionen

Info

Publication number: DE112011101759B4
Application number: DE112011101759.6T
Authority: DE
Inventors: Kean Kuiper; Enio Manuel Pineda; Frank Eliot Levine
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-05-24
Filing date: 2011-05-11
Publication date: 2015-03-05
Anticipated expiration: 2031-05-12
Also published as: US9176783B2; CN102893261A; DE112011101759T5; GB2493609B; WO2011147685A1; US20110289361A1; CN102893261B; GB2493609A; GB201212738D0

Abstract

Ein Prozess erstellt ein Muster auf der Grundlage eines Ereignisses. Der Prozess erkennt, mithilfe eines Zuteilungsmonitors, einen nächsten zugeteilten überwachten Thread, der durch einen aktuellen Prozessor zugeteilt wird. Der Prozess stellt eine Prozessoraffinität des nächsten zugeteilten überwachten Threads so ein, dass der nächste zugeteilte überwachte Thread nur auf dem aktuellen Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können. Der Prozess ruft außerdem, mithilfe eines Threads, von dem ein Muster genommen wurde, der auf dem aktuellen Prozessor läuft, eine Aufrufliste eines nächsten zugeteilten überwachten Threads ab, nachdem die Prozessoraffinität des nächsten zugeteilten überwachten Threads auf den Prozessor eingestellt wurde. Der Prozess stellt die Prozessoraffinität des nächsten zugeteilten überwachten Threads wieder her, nachdem die Aufrufliste des nächsten zugeteilten überwachten Threads abgerufen wurde.

Description

Technisches Fachgebiet
Die Erfindung betrifft allgemein eine Rechenumgebung. Die Offenbarung betrifft insbesondere Sampling-Technologie (Mustererstellungstechnologie).
Hintergrund
Bei Anwendungs-Profiling-Werkzeugen wird entweder Zeit-basierte oder Hardwareereignis-basierte Sampling-Technologie verwendet, um die spezifische Nutzung von Betriebsmitteln festzustellen. Ein aktueller Ansatz besteht darin, periodisch einen Interrupt zu erzeugen, um ein Sample zu nehmen. Während des Interrupts werden Sample-Daten gesammelt und aufgezeichnet. Beispiele für die Sample-Daten sind der unterbrochene Prozess/Thread, die gerade ausgeführte Instruktion oder optional die Datenadresse, auf die zur Zeit der Sample zugegriffen wird. Zu einem späteren Zeitpunkt werden die gesammelten Daten aggregiert, und es werden Berichte erstellt, die die Sample-Verteilung nach Adresse, Symbol, Prozess usw. darstellen. Verschiedene Werkzeuge basieren auf dieser Technologie. Der vollständige Ausführungskontext der Sample wird üblicherweise nicht aufgezeichnet und steht nicht in Berichten zur Verfügung.
Es wurden Versuche unternommen, diese Technologie durch Erfassen von Call-Stacks zur Zeit des Samplens zu verbessern. Mithilfe des vorhandenen Werkzeugsatzes kann entweder versucht werden, den Call-Stack direkt zu durchlaufen oder in einem separaten (Sampler-)Thread Funktionen aufzurufen, um den Call-Stack des unterbrochenen Threads zu erhalten. Der Versuch, den Call-Stack auf der Interrupt-Ebene zu durchlaufen, ist nicht ideal, da einige Anwendungen Listen haben können, die ausgelagert wurden. Außerdem nimmt zum Durchlaufen von Call-Stacks bestimmter Code üblicherweise Speicherzuweisungen vor, die auf der Interrupt-Ebene nicht zulässig sind. Dadurch kann ein Sampling-Thread im Benutzermodus dazu verwendet werden, auf Anforderung die Call-Stacks zu durchlaufen. Bei Mehrprozessorsystemen kann die Anforderung, dass ein separater Thread den Call-Stack des unterbrochenen Threads erfassen soll, es dem unterbrochenen Thread ermöglichen, zu einem anderen Prozessor zu migrieren und weiter fortzuschreiten, d. h. weiter ausgeführt zu werden, während der Call-Stack erfasst wird. Der erfasste Call-Stack spiegelt dann nicht den Status des Threads zum Zeitpunkt seiner Unterbrechung wider.
Kurzdarstellung
Gemäß einem Aspekt der Erfindung wird ein System zum Anwendungs-Profiling von auf mehreren Prozessoren ablaufenden Threads bereitgestellt. Das System enthält einen Prozessor, der auf der Grundlage eines Ereignisses ein Sample erstellt. Das System enthält weiter ein Betriebssystem, das (i) mithilfe eines Zuteilungsmonitors bzw. eines Dispatch-Monitors einen nächsten zugeteilten überwachten Thread erkennt, der einen aktuellen Prozessor zugeteilt wird, und das (ii) die Prozessoraffinität des nächsten zugeteilten überwachten from_Idle-Threads mittels eines Schedulers so einstellt, dass der nächste zugeteilte überwachte from_Idle-Thread nur auf dem aktuellen Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können.
Außerdem enthält das System einen Profiler, der angepasst ist, dass er die Prozessoraffinität des nächsten zuzuteilenden überwachten to_Idle-Thread festgelegt, so dass der nächste zuzuteilende überwachte to_Idle-Thread nur auf dem Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können.
Außerdem ist der Profiler angepasst, dass er mithilfe eines Sampler-Threads, der so konfiguriert ist, dass er nur auf dem aktuellen Prozessor läuft, einen Call-Stack eines nächsten zugeteilten überwachten Threads abruft, nachdem die Prozessoraffinität des nächsten zugeteilten überwachten Threads auf den aktuellen Prozessor eingestellt wurde, so dass ein Kontext des nächsten zuzuteilenden Thread festgestellt wird, (ii) die Prozessoraffinität des nächsten zugeteilten überwachten Threads wieder herstellt, nachdem der Call-Stack des nächsten zugeteilten, überwachten Threads abgerufen wurde, und (iii) der Call-Stack für den nächsten zugeteilten überwachten Thread aufzeichnet.
Kurze Beschreibung der Zeichnungen
Im Folgenden werden Ausführungsformen der Erfindung ausschließlich beispielhaft beschrieben, und zwar unter Bezugnahme auf die begleitenden Zeichnungen, die Folgendes zeigen:
1 veranschaulicht ein Sampling-System gemäß einer Ausführungsform der vorliegenden Erfindung, das Sample von Leerlauftransitionen nimmt.
2A veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Interrupt-Handler für einen to_idle_thread (letzter Thread vor dem Leerlauf) verwendet werden kann.
2B veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Interrupt-Handler für einen from_idle_thread (erster Thread nach dem Leerlauf) verwendet werden kann.
3A veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Dispatch-Monitoring-Code in dem Scheduler für einen to_idle_thread verwendet werden kann.
3B veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Dispatch-Monitoring-Code in dem Scheduler für einen from_idle_thread verwendet werden kann.
4 veranschaulicht einen Prozess zur Benachrichtigung des Profilers gemäß einer Ausführungsform der vorliegenden Erfindung.
5 veranschaulicht gemäß einer Ausführungsform der vorliegenden Erfindung einen Prozess für das Interrupt-Backend, das bei dem Prozessblock in eine Warteschlange „gequeued” ist.
6 veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Profiler ausgeführt wird, nachdem dieser als Folge des Prozessblocks aktiviert wurde.
7 veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, bei dem der Profiler das Betriebssystem darüber informiert, dass das Sample fertig gestellt wurde.
8A veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der für das Sampling von Leerlauftransitionen für einen from_idle_thread verwendet werden kann.
8B veranschaulicht einen Prozess gemäß einer Ausführungsform der vorliegenden Erfindung, der für das Sampling von Leerlauftransitionen für einen to_idle_thread verwendet werden kann.
9 veranschaulicht ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung, das Sample von Leerlauftransitionen nimmt.
Ausführliche Beschreibung
Ein Verfahren und System verwenden Sampling-Technologie, um festzustellen, warum ein oder mehrere Prozessoren nicht ausgelastet sind. Es kann sehr schwierig sein, festzustellen, warum eine auf dem Prozessor oder den Prozessoren laufende Anwendung nicht skaliert. Bei einigen Umgebungen, besonders denjenigen, die Transaktionsverarbeitung unterstützen, ist es wichtig, die maximale Transaktionsrate festzustellen und das System dazu zu veranlassen, alle Verarbeitungsbetriebsmittel in vollem Umfang zu nutzen. Wenn die maximale Transaktionsrate erreicht wird, aber nicht alle Prozessoren ausgelastet sind, liegt eine Art von Engpass vor, der die vollständige Auslastung verhindert. Durch Feststellen des Kontextes für den letzten Thread, der ausgeführt wurde, bevor ein Prozessor in den Leerlauf (idle) ging, d. h. der to_idle_thread und/oder des Kontextes für den ersten Thread, der ausgeführt wird, sobald der Prozessor beschäftigt ist, d. h. der from_idle_thread, erhält man möglicherweise Informationen, die dazu beitragen, die Ursache des Engpasses festzustellen.
Ein Ansatz besteht darin, alle Call-Stacks für diejenigen Threads zu erfassen, die zu einem Engpass beigetragen haben könnten. Das heißt zum Beispiel, der Sampling-Code könnte einfach Call-Stacks nur für diejenigen Threads beschaffen, die kürzlich auf dem Prozessor gelaufen sind, der sich zur Zeit des Sampling im Leerlauf befindet. Dies beinhaltet, zu verfolgen, welcher Thread auf welchem Prozessor gelaufen ist, um die Call-Stacks für die richtigen Threads zu erfassen. Diese Threads können jedoch migrieren und auf anderen Prozessoren ausgeführt werden, während Call-Stacks erfasst werden.
Alle Prozessoren beschäftigt zu halten, mit Ausnahme desjenigen, dessen Call-Stack erfasst wird, kann möglicherweise eine Thread-Migration verhindern. Dies könnte dadurch erreicht werden, dass man Sampler-Threads auf diesen Prozessoren eine Überwachung ausführen lässt, bis der Call-Stack für den interessierenden Thread vorliegt, aber dies könnte die gesamte Anwendungsleistung beeinträchtigen.
Indem stattdessen der interessierende Thread an der Migration zu einem anderen Prozessor gehindert wird, was bei einer Ausführungsform durchgeführt werden kann, indem seine Prozessoraffinität so eingestellt wird, dass er nur auf einem Prozessor laufen kann, müssen die anderen Prozessoren keine Überwachungsvorgänge ausführen, so dass die anderen Prozessoren frei für das weitere Ausführen der Anwendung sind. Durch das Verhindern der Thread-Migration tritt daher nur eine minimale Verschlechterung der Anwendungsleistung auf. Anstatt die Leistung der Anwendung, deren Profil erstellt wird, stark zu beeinträchtigen, indem alle Sampler-Threads aktiviert werden, d. h. einer pro Prozessor, und Überwachungsvorgänge ausführen, bis die Call-Stacks abgerufen sind, könnten ein Verfahren, System und Computerprogrammprodukt die Prozessoraffinität so einstellen, dass Thread-Migration bei minimaler Beeinträchtigung der Leistung der Anwendung, deren Profil erstellt wird, verhindert wird und außerdem das Sampling von Leerlauftransitionen ermöglicht wird. Bei einer Ausführungsform wird für bereits angesehene Call-Stacks lediglich ein Zählwert des Vorkommens (occurrence count) inkrementiert.
To_idle-Verarbeitung und/oder from_idle-Verarbeitung können verwendet werden, um die Prozessoraffinität so einzustellen, dass Thread-Migration verhindert wird. Es wird ein Sampling-Ansatz verwendet.
1 veranschaulicht ein Sampling-System 100 gemäß einer Ausführungsform der vorliegenden Erfindung, das Sample von Leerlauftransitionen nimmt. Das Sampling-System 100 enthält eine Anwendung 102, die mit einem Profiler 104 interagiert, der ein Profil der Anwendung 102 erstellt. Der Profiler 104 interagiert mit einem Betriebssystem 106. Der Profiler 104 trägt dazu bei, festzustellen, warum ein Prozessor nicht ausgelastet ist, d. h., wodurch verursacht wird, dass ein Prozessor im Leerlauf ist, anstelle nützliche Arbeit zu verrichten. Die Verarbeitung basiert auf Sampling, wenn die Prozessoren im Leerlauf sind. Da Call-Stacks zur Zeit des Sampling erfasst werden, wird der Code, der potenziell zu dem Leerlaufzustand beiträgt, genau festgestellt. Die Position des Codes sowie die Aufrufsequenz, die zum Vorhandensein des Codes an dieser Stelle führte, werden ermittelt.
Gleichzeitig mit dem Sampling überwacht der Scheduler 108 Thread-Zuteilungen mithilfe von Zuteilungsüberwachungscode (dispatch monitoring code). Dieser Code ist entweder Teil des Betriebssystems oder wird mithilfe eines Device-Treibers oder einer Kernel-Erweiterung hinzugefügt. Es können auch Daten hinsichtlich des to_thread und/oder from_thread gespeichert werden. Asynchron zueinander laufen einige Vorgänge ab: Der Dispatch-Monitoring-Code überwacht Thread-Zuteilungen. Weiterhin werden von den Prozessoren mit konstanter Häufigkeit Samples erstellt, d. h. Zeit-basiert oder bei jedem n-ten Auftreten eines Ereignisses, d. h. Ereignis-basiert. Außerdem „lauschen” Sampler-Threads auf Befehle, die sie dazu veranlassen würden, den Call-Stack eines interessierenden Threads abzurufen, was von dem Profiler 104 ausgeführt wird. Ein Sampler-Thread ist ein Profiler-Thread. Es können zahlreiche Sampler-Threads verwendet werden, da eine Mehrzahl von Prozessoren verwendet werden kann. Jeder Sampler-Thread hat eine Affinität zu einem einzigen Prozessor. Sampler-Threads können Threads mit einer sehr hohen Priorität sein, so dass sie sofort ausgeführt werden, wenn sie das Signal erhalten, Arbeit zu verrichten, wie beispielsweise Call-Stack eines Ziel-Threads abzurufen. Der Ziel-Thread ist der Thread, dessen Call-Stack abgerufen werden soll. Überdies ist ein Ziel-Prozessor der Prozessor, auf dem der Ziel-Thread ausgeführt wurde und auf dem die Affinität so eingestellt ist, dass der Ziel-Thread auf diesem Prozessor verbleibt, bis sein Call-Stack erfasst wurde.
Sobald als Ergebnis des Samplings entweder des to_idle oder des from_idle eine Feststellung getroffen wird, ist der Call-Stack eines Ziel-Threads abzurufen. Es wird verhindert, dass der Ziel-Thread während dieser Zeit in irgendeiner Weise fortschreitet, es sei denn, ein Fortschreiten wäre für den Abruf des Call-Stack erforderlich. Mit anderen Worten wird der Ziel-Thread an seinem Platz gehalten, bis der Call-Stack erfasst ist. Danach kann der Ziel-Thread fortgesetzt werden. Da Call-Stacks von Profiler-Sampler-Threads erfasst werden, könnte der Ziel-Thread potenziell auf einem anderen verfügbaren Prozessor zu laufen beginnen. Zu dem Zeitpunkt, an dem der Sampler-Thread mit dem Erfassen des Call-Stack beginnt, befindet sich der Ziel-Thread möglicherweise nicht mehr an dem Punkt, an dem ein Sample erstellt wurde, und der Call-Stack würde nicht genau widerspiegeln, wo sich der Ziel-Thread zur Zeit des Sampling befand.
Anstatt die Anwendungsleistung durch „Wegboxen” des Ziel-Threads von anderen Prozessoren als dem Ziel-Prozessor deutlich zu behindern (d. h., alle anderen Prozessoren mit nutzloser Arbeit zu beschäftigen, um sie Überwachungsvorgänge ausführen zu lassen, so dass sie für eine Ausführung des Ziel-Threads nicht zur Verfügung stehen), wird die Gruppe der Prozessoren, auf denen der Ziel-Thread laufen könnte, auf den Ziel-Prozessor beschränkt. Mit anderen Worten führen die verbleibenden Prozessoren keine Überwachungsvorgänge aus und können weiterhin echte Arbeit verrichten. Nur der Ziel-Prozessor ist betroffen, während der Call-Stack des Ziel-Threads abgerufen wird. Sobald der Call-Stack des Ziel-Threads abgerufen wurde, kann der Ziel-Thread wieder auf jedem verfügbaren Prozessor laufen. Die Prozessoraffinität ist so eingestellt, dass der Ziel-Thread nur auf dem einen Prozessor laufen kann, zu dem er eine Affinität hat.
Das Sampling-System 100 kann über eine Mehrzahl von Prozessoren verfügen. Beispielsweise kann das Sampling-System 100 über einen ersten Prozessor 112, einen zweiten Prozessor 114, ..., und einen n-ten Prozessor 116 verfügen. Zu einer gegebenen Zeit kann auf jedem Prozessor nur ein Thread laufen. Dieser Thread kann jedoch potenziell auf einem anderen Prozessor und zu einer anderen Zeit laufen. Bei dem Sampling-System 100 erzeugen ein oder mehrere Prozessoren entweder Zeit- oder Ereignis-basiert Interrupts. Ein Interrupt kann ein Sampling einleiten. Folglich kann jeder der Prozessoren unabhängig von dem Status jedes anderen Prozessors einen Interrupt erzeugen, z. B. unabhängig davon, ob sich dieser im Leerlauf befindet oder nicht. Der Interrupt für jeden Prozessor wird durch Hardware erzeugt und durch einen Interrupt-Handler 110 gehandhabt, der feststellt, ob der Prozessor, auf dem der Interrupt auftrat, sich im Leerlauf befindet, d. h., ob auf diesem speziellen Prozessor kein Thread ausgeführt wird, oder ob er sich nicht im Leerlauf befindet. Der Interrupt-Handler 110 leitet das Erfassen von Call-Stacks ein. Darüber hinaus kann der Interrupt-Handler einen Profiler-Sampler-Thread benachrichtigen oder diesem ein Signal senden. Bei einer Ausführungsform und wenn der Interrupt-Handler 110 feststellt, dass ein bestimmter Prozessor sich im Leerlauf befindet, kann der Interrupt-Handler 110 einem Scheduler 108 ein Flag wie beispielsweise ein Flag „Zeitverzögerte Verarbeitung” senden, der dann das Ausführen eines Sampler-Threads auf diesem speziellen Prozessor einplanen kann oder auch nicht, um ein Sample des Ziel-Threads zu nehmen. Um während des Sampling eine Thread-Migration zu verhindern, kann die Prozessoraffinität eines Threads zu einem bestimmten Prozessor festgelegt werden. Für einen from_idle-Thread legt der Scheduler 108 die Prozessoraffinität fest. Für einen to_idle-Thread können der Interrupt-Handler 110 oder der Profiler 104 die Prozessoraffinität festlegen.
Während der from_idle-Verarbeitung kann eine Benachrichtigung von dem Scheduler 108 an den Profiler 104 gesendet werden. Der erste interessierende überwachte Thread, der aktiviert und ausgeführt wird, nachdem ein Prozessor sich im Leerlauf befindet, ist wahrscheinlich der Thread, der den Engpass verursacht. Während das System läuft, wartet der Dispatch-Monitoring-Code darauf, mitgeteilt zu bekommen, dass er den nächsten interessierenden Thread speichern soll, der ausgeführt wird, z. B. indem er das Setzen des Flag „Zeitverzögerte Verarbeitung” beobachtet. Der Sampling-Code teilt dem Dispatch-Monitoring-Code dies mit, indem er nach einem Sampling, bei der sich der Prozessor im Leerlauf befindet, ein Flag „Zeitverzögerte Verarbeitung” sendet/setzt. Der Dispatch-Monitoring-Code speichert den ersten interessierenden/überwachten Thread, der läuft, nachdem bei einem vorhergehenden Sampling entdeckt wurde, dass der Prozessor sich im Leerlauf befindet. Zu derselben Zeit, in der Samples anfallen, wird eine Feststellung getroffen, ob der Prozessor sich im Leerlauf befindet oder nicht. Wenn der Prozessor beschäftigt ist, wird nichts unternommen. Wenn der Prozessor sich im Leerlauf befindet, wird das Flag „Zeitverzögerte Bearbeitung” gesetzt, damit der Dispatch-Monitoring-Code mit der Überwachung von Thread-Zuteilungen beginnt und den nächsten interessierenden/überwachten Thread speichert, der auf dem Prozessor eingeplant werden soll. Der Dispatch-Monitoring-Code entfernt anschließend das Flag „Zeitverzögerte Bearbeitung”. Das Sample wird dann fertig gestellt.
Dieselbe Verarbeitung kann auf mehr als einem Prozessor gleichzeitig stattfinden. Wenn sich beispielsweise zwei Prozessoren im Leerlauf befinden und zufällig ungefähr zu derselben Zeit interessierende Threads zuteilen, dann können zwei Sampler-Threads zu derselben Zeit Call-Stacks abrufen.
Überdies kann eine to_idle-Benachrichtigung von dem Interrupt-Handler 110 an den Profiler 104 gesendet werden. Der letzte interessierende/überwachte Thread, der auf einem Prozessor läuft, bevor dieser in den Leerlauf geht, ist wahrscheinlich von einem Konflikt einiger Betriebsmittel betroffen. Beispielsweise schreitet der Thread möglicherweise nicht fort, weil er auf ein Betriebsmittel wartet, hinsichtlich dessen ein Konflikt besteht. Nach einem to_idle thread stehen keine anderen Threads zur Ausführung zur Verfügung. Während das System läuft, merkt sich der Dispatch-Monitoring-Code den letzten interessierenden Thread, der auf jedem Prozessor ausgeführt wurde. Da er sich den Thread, den er sich jetzt merkt, vorher auf einem anderen Prozessor gemerkt haben könnte, wird dieser von der Merkliste des anderen Prozessors entfernt. Gleichzeitig fallen periodisch Samples an, die entweder Zeit- oder Ereignis-basiert sind. Bei jedem Sample wird eine Feststellung darüber getroffen, ob der Prozessor sich im Leerlauf befindet oder nicht. Wenn der Prozessor beschäftigt ist, wird nichts unternommen. Wenn der Prozessor sich im Leerlauf befindet, wird eine Feststellung darüber getroffen, ob ein interessierender überwachter Thread zuletzt auf dem Prozessor gelaufen ist. Wenn ein interessierender Thread zuletzt auf dem Prozessor gelaufen ist, dann wird die Prozessoraffinität des Threads auf den aktuellen Prozessor eingestellt.
Bei einer Ausführungsform wird nur der from_idle_thread verwendet. Bei einer alternativen Ausführungsform wird nur der to_idle_thread verwendet. Bei noch einer anderen alternativen Ausführungsform werden sowohl der from_idle_thread als auch der to_idle_thread verwendet.
Bei einer anderen Ausführungsform kann eine Komponente wie beispielsweise ein Dispatch-Monitor in Verbindung mit dem Scheduler 108 verwendet werden. Der Dispatch-Monitor kann Teil des Betriebssystems 106 sein oder kann als Teil einer Kernel-Erweiterung oder eines Device-Treibers hinzugefügt werden. Bei einer anderen Ausführungsform kann eine Komponente wie beispielsweise ein Interrupt-Backend-Worker, Offlevel-Processing-Worker, Interrupt-Backend-Worker oder Ähnliches als Teil einer Kernel-Erweiterung oder eines Device-Treibers hinzugefügt werden. Die Komponente wird benötigt, da die Gruppe von Aktionen, die auf Interrupt-Ebene ausgeführt werden kann, begrenzt ist, und ein Teil der Arbeit bis zu einem späteren Zeitpunkt verzögert werden muss, wenn der Interrupt-Handler beendet ist.
Der Profiler 104 kann den Call-Stack, d. h. den Ausführungskontext, abrufen. Der Profiler 104 kann weiter die Prozessoraffinität wiederherstellen.
2A veranschaulicht einen Prozess 200 gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Interrupt-Handler 110 für einen to_idle_thread verwendet werden kann. Bei einem Prozessblock 202 stellt der Prozess 200 eine ID eines unterbrochenen Prozesses („PID”) und/oder eines unterbrochenen Threads („TID”) fest. Bei einem Entscheidungsblock 204 stellt der Prozess 200 weiter fest, ob der Mikroprozessor sich im Leerlauf befindet. Wenn der Mikroprozessor sich nicht im Leerlauf befindet, schreitet der Prozess 200 zu einem Prozessblock 210 fort, um den unterbrochenen Thread fortzusetzen. Wenn sich alternativ der Mikroprozessor im Leerlauf befindet, schreitet der Prozess 200 zu einem Entscheidungsblock 206 fort, um festzustellen, ob eine gespeicherte to_idle-PID, die von dem Dispatch-Monitoring-Code gespeichert wurde, von Interesse ist. Wenn die gespeicherte to_idle-PID nicht von Interesse ist, schreitet der Prozess 200 zu dem Prozessblock 210 fort, um in dem unterbrochenen Thread fortzufahren. Wenn alternativ die gespeicherte to_idle-PID von Interesse ist, schreitet der Prozess 200 zu einem Prozessblock 208 fort, um den Profiler zu benachrichtigen. Der Prozess 200 schreitet dann zu einem Prozessblock 210 fort, um den unterbrochenen Thread fortzusetzen.
2B veranschaulicht einen Prozess 250 gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Interrupt-Handler 110 für einen from_idle_thread verwendet werden kann. Bei einem Prozessblock 252 stellt der Prozess 250 eine ID eines unterbrochenen Prozesses (PID = interrupted process ID) oder eine ID eines unterbrochene Threads (TID = unterbrocher Thread) fest. Bei einem Entscheidungsblock 254 stellt der Prozess 250 weiter fest, ob der Mikroprozessor sich im Leerlauf befindet. Wenn der Mikroprozessor sich nicht im Leerlauf befindet, schreitet der Prozess 250 zu einem Prozessblock 258 fort, um den unterbrochenen Thread fortzusetzen. Wenn sich alternativ der Mikroprozessor im Leerlauf befindet, schreitet der Prozess 250 zu einem Entscheidungsblock 255 fort, um festzustellen, ob das Flag „Zeitverzögerte Bearbeitung” schon gesetzt wurde. Wenn das Flag „Zeitverzögerte Bearbeitung” schon gesetzt wurde, schreitet der Prozess 250 zu dem Prozessblock 258 fort, um den unterbrochenen Thread fortzusetzen. Wenn das Flag „Zeitverzögerte Bearbeitung” noch nicht gesetzt wurde, schreitet der Prozess 250 zu einem Prozessblock 256 fort, um ein Flag „Zeitverzögerte Bearbeitung” für den Scheduler 108 zu setzen. Der Prozess 250 schreitet dann zu einem Prozessblock 258 fort, um den unterbrochenen Thread fortzusetzen.
3A veranschaulicht einen Prozess 300 gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Scheduler 108 für einen to_idle_thread verwendet werden kann. Bei einem Entscheidungsblock 302 stellt der Prozess 300 fest, ob ein ausgehender Thread existiert, der von Interesse ist. Wenn kein ausgehender Thread existiert, der von Interesse ist, schreitet der Prozess 300 zu einem Prozessblock 306 fort, um den Thread-Wechsel (thread switch) fortzusetzen. Wenn ein ausgehender Thread existiert, der von Interesse ist, schreitet der Prozess 300 zu einem Prozessblock 304 fort, um die ausgehende PID und/oder TID zu speichern. Der Prozess 300 schreitet dann zu einem Prozessblock 305 fort, um die ausgehende PID/TID aus der gespeicherten PID/TID-Liste des anderen Prozessors zu entfernen. Der Prozess 300 schreitet dann zu dem Prozessblock 306 fort, um den Thread-Wechsel fortzusetzen.
3B veranschaulicht einen Prozess 350 gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Scheduler 108 für einen from_idle_thread verwendet werden kann. Bei einem Entscheidungsblock 352 stellt der Prozess 350 fest, ob das Flag „Zeitverzögerte Verarbeitung” gesetzt wurde. Wenn das Flag „Zeitverzögerte Bearbeitung” nicht gesetzt wurde, schreitet der Prozess 350 zu einem Prozessblock 360 fort, um den Thread-Wechsel fortzusetzen. Wenn alternativ das Flag „Zeitverzögerte Bearbeitung” gesetzt wurde, schreitet der Prozess 350 zu einem Entscheidungsblock 354 fort, um festzustellen, ob ein eingehender Thread existiert, der von Interesse ist. Wenn kein eingehender Thread existiert, der von Interesse ist, schreitet der Prozess 350 zu einem Prozessblock 360 fort, um den Thread-Wechsel fortzusetzen. Wenn alternativ ein eingehender Thread existiert, der von Interesse ist, schreitet der Prozess 350 zu einem Prozessblock 356 fort, um das Flag „Zeitverzögerte Bearbeitung” zurückzusetzen. Der Prozess 350 schreitet dann zu einem Prozessblock 358 fort, um den Profiler 104 zu benachrichtigen. Der Prozess 350 schreitet dann weiter zu dem Prozessblock 350 fort, um den Thread-Wechsel fortzusetzen.
4 veranschaulicht einen Prozess 400 zur Benachrichtigung des Profilers 104 gemäß einer Ausführungsform der vorliegenden Erfindung. Bei einem Entscheidungsblock 402 stellt der Prozess 400 fest, ob ein Profiler zu benachrichtigen ist. Wenn kein Profiler zu benachrichtigen ist, schreitet der Prozess 400 zu einem Abschlussblock 408 fort. Wenn alternativ ein Profiler zu benachrichtigen ist, schreitet der Prozess 400 zu einem Prozessblock 404 fort, um die Benachrichtigungsdaten zu sichern und/oder zu speichern. Der Prozess 400 schreitet zu einem Prozessblock 406 fort, um das Interrupt-Backend in eine Warteschlange einzureihen. Als Folge davon wird eine Arbeitsaufgabe durch das Betriebssystem 106 in eine Warteschlange eingereiht. Eine der Informationen in dieser Arbeitsaufgabe ist die Adresse der Worker-Funktion (Arbeitsfunktion), die auszuführen ist, wenn das Interrupt-Backend durch das Betriebssystem 106 aus der Warteschlange entfernt wird. Der Prozess 400 schreitet dann zu einem Abschlussblock 408 fort.
5 veranschaulicht einen Prozess 500 für das Verhalten des Interrupt-Backend in dem Prozessblock 406 gemäß einer Ausführungsform der vorliegenden Erfindung. Bei einem Prozessblock 502 zeigt der Prozess 500 ein ausstehendes Sample an. Weiter schreitet der Prozess 500 dann zu einem Prozessblock 504 fort, um die Prozessoraffinität des Ziel-Threads auf den aktuellen Prozessor einzustellen. Darüber hinaus schreitet der Prozess 500 dann zu einem Prozessblock 506 fort, um den Profiler zu aktivieren.
6 veranschaulicht einen Prozess 600 gemäß einer Ausführungsform der vorliegenden Erfindung, der von dem Profiler ausgeführt wird, nachdem diesem als Folge des Prozessblocks 506 entweder von dem Interrupt-Handler oder von dem Scheduler ein Signal gesendet wurde. Bei einem Prozessblock 602 lässt der Prozess 600 den Profiler auf ein Ereignis oder Signal warten. Das Ereignis oder Signal kommt von dem Interrupt-Handler 110, wenn der Thread ein to_idle-Thread ist. Das Ereignis oder Signal kommt von dem Scheduler 108, wenn der Thread ein from_idle-Thread ist. Bei einem Prozessblock 604 empfängt der Prozess 600 weiter das Signal von dem Betriebssystem 106. Bei einem Prozessblock 606 liest der Prozess 600 überdies die Sample-Daten, die Informationen über den Ziel-Thread enthalten. Bei einem Prozessblock 608 fordert der Prozess 600 den Call-Stack für den Ziel-Thread an. Bei einem Prozessblock 610 stellt der Prozess 600 weiter die Prozessoraffinität des Ziel-Threads wieder her. Bei einem Prozessblock 612 verarbeitet der Prozess 600 den zurückgegebenen Call-Stack. Bei einer Ausführungsform kann das Verarbeiten des zurückgegebenen Call-Stacks das Speichern des zurückgegebenen Call-Stacks in einer Baumstruktur beinhalten. Weiter können ein to_idle-Zählwert und/oder ein from_idle-Zählwert inkrementiert werden. Der to_idle-Zählwert oder der from_idle-Zählwert zeigen an, wie viele Male der Call-Stack, d. h. die Aufrufsequenz, an dem Blattknoten endete. Bei einem Prozessblock 614 informiert der Prozess 600 das Betriebssystem 106 darüber, dass das Sample fertig gestellt wurde. Der Prozess 600 kehrt dann zu dem Prozessblock 602 zurück, um auf ein Ereignis oder Signal zu warten.
7 veranschaulicht einen Prozess 700 gemäß einer Ausführungsform der vorliegenden Erfindung, bei dem das Betriebssystem 106 darüber informiert wird, dass das Sample fertig gestellt wurde. Bei einem Prozessblock 702 wurde ein Sample fertig gestellt. Bei einem Prozessblock 704 zeigt der Prozess 700 weiter an, dass keine ausstehenden Samples existieren. Auf einem Prozessor mit einem ausstehenden Sample werden keine weiteren Samples eingeleitet. Bei einem Prozessblock 706 reinitialisiert der Prozess 700 zudem Interrupts.
Bei einer Ausführungsform kann das Melden der Leerlauftransition für den letzten Thread, der überwacht wurde, bevor der Prozessor in den Leerlauf ging, durch Nachhalten eines lastdispatched Eintrags in einer jedem Prozessor zugeordneten Tabelle unterstützt werden. Wenn ein Zeit-basiertes Muster anfällt und das Muster einen Prozessor im Leerlauf unterbricht, wird der Sampler-Thread aktiviert und beschafft die Call-Stack des letzten überwachten Threads. Dessen Call-Stack wird in einer Baumstruktur gespeichert, und der to_idle-Zählwert des Blattknotens der gerade eingefügten Call-Stack wird inkrementiert. Um eine Call-Stack des überwachten from_idle-Threads zu erhalten, die dessen Zustand zu der Zeit widerspiegelt, zu der der Leerlauf begann, muss entweder die Call-Stack zu der Zeit abgerufen werden, wenn der Prozessor sich im Leerlauf befindet, oder zu der Zeit, wenn festgestellt wird, dass der Thread zugeteilt werden soll, bevor die Möglichkeit eintritt, dass der Thread ausgeführt wird. In jedem Fall wird die Call-Stack für den ersten überwachten Thread, der zugeteilt wird, nachdem ein to_idle-Sample genommen wurde, in einem Baum gespeichert, und der from_idle-Zählwert des Blattknotens der gerade eingefügten Call-Stack wird inkrementiert. Berichte können erstellt und angezeigt werden.
Wenn ein Sample genommen und festgestellt wird, dass der Prozessor sich im Leerlauf befindet, zeigt der Sampling-Code dem Dispatch-Monitoring-Code an, dass von dem nächsten zugeteilten überwachten Thread auf diesem Prozessor ein Sample erstellt werden muss. Dieser Thread wird in dem jedem Prozessor zugeordneten Kontrollblock gekennzeichnet und nicht aktualisiert, bevor das nächste Sample genommen wird.
Wenn der Dispatch-Monitoring-Code erkennt, dass eine Call-Stack eines from_idle-Threads aufgezeichnet werden sollte und der zuzuteilende Thread ein überwachter Thread ist, dann kann er dafür sorgen, dass stattdessen der Sampler-Thread zugeteilt wird. Bei einer Ausführungsform kann dies ausgeführt werden, indem ein Interrupt-Backend oder Second-Level-Interrupt-Handler mit einem Hinweis in eine Warteschlange eingereiht wird, zu erzwingen, dass der Sampling-Thread den Call-Stack für den überwachten Thread verarbeitet. Bei einer anderen Ausführungsform kann der Dispatch-Monitoring-Code direkt erzwingen, dass der Sampling-Thread als nächster zugeteilt wird, und zwar mit den Informationen, die dafür benötigt werden, den Call-Stack für den überwachten Thread zu erhalten. Diese Information könnte durch einfaches Aktualisieren der Kennzeichnung des überwachten from_idle-Threads in einem zugeordneten Sample-Datenbereich weitergegeben werden.
Wenn der Call-Stack für den from_idle-Thread nicht abgerufen werden kann, bevor dieser zugeteilt wird, dann können Call-Stacks für aktuell nicht ausgeführte Threads zu einer Zeit abgerufen werden, wenn der Prozessor sich im Leerlauf befindet. Die Stacks können auf eine Untergruppe beschränkt sein, wie beispielsweise nur die, die auf dem Prozessor, der sich im Leerlauf befindet, zuletzt zugeteilt wurden. Es kann auch andere Kriterien geben, beispielsweise Ausschließen von Threads, die keine zuvor zurückgegebenen Stacks aufweisen, oder von Threads, die als Daemon-Threads erkannt werden. Wenn der Stack des from_idle-Threads zu der Zeit erfasst wurde, als der Prozessor sich im Leerlauf befand, dann kann dieser zuvor erfasste Call-Stack zu einem späteren Zeitpunkt verwendet werden, beispielsweise beim nächsten Sample. Die Untergruppe von Threads kann auf nur diejenigen beschränkt sein, die auf dem Prozessor, der sich im Leerlauf befindet, zuletzt zugeteilt wurden. Verschiedene Sampler-Threads könnten Stacks gleichzeitig abrufen. Mit gewissen Logikelementen ließe sich der Stack der Threads erkennen, deren Call-Stacks abgerufen werden, und um sicherzustellen, dass diese nicht als Folge von Timing-Problemen auf einem anderen Prozessor dupliziert werden.
8A veranschaulicht einen Prozess 800 gemäß einer Ausführungsform der vorliegenden Erfindung, der für das Sampling von Leerlauftransitionen für einen from_idle_thread verwendet werden kann. Bei einem Prozessblock 802 erstellt der Prozess 800 ein Sample auf der Grundlage eines Ereignisses. Bei einem Prozessblock 804 erkennt der Prozess 800 weiter mithilfe eines Dispatch-Monitors einen nächsten zugeteilten überwachten Thread, der durch einen Prozessor zugeteilt wird, wenn auf der Grundlage des Interrupts festgestellt wird, dass sich der Prozessor im Leerlauf befindet. Zudem stellt bei einem Prozessblock 806 der Prozess 800 eine Prozessoraffinität des nächsten zugeteilten überwachten Threads so ein, dass der nächste zugeteilte überwachte Thread nur auf dem Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können. Bei einem Prozessblock 808 ruft der Prozess 800 mithilfe eines Threads, von dem ein Sample erstellt wurde – bzw. eines vermusterten Threads bzw. Sample-basierenden Threads – und der auf dem Prozessor läuft, einen Call-StackCall-Stack eines nächsten zugeteilten überwachten Threads ab, nachdem die Prozessoraffinität des nächsten zugeteilten überwachten Threads auf den Prozessor eingestellt wurde. Bei einem Prozessblock 810 stellt der Prozess 800 zudem die Prozessoraffinität des nächsten zugeteilten überwachten Threads wieder her, nachdem der Call-Stack des nächsten zugeteilten überwachten Threads abgerufen wurde. Bei einem Prozessblock 812 zeichnet der Prozess 800 den Call-Stack für den nächsten zugeteilten überwachten Thread auf. Die Aufzeichnung kann die Form eines Berichts haben.
8B veranschaulicht einen Prozess 850 gemäß einer Ausführungsform der vorliegenden Erfindung, der für das Sampling von Leerlauftransitionen für einen to_idle_thread verwendet werden kann. Bei einem Prozessblock 852 erstellt der Prozess 850 ein Sample auf der Grundlage eines Ereignisses. Bei einem Prozessblock 854 erkennt der Prozess 850 weiter mithilfe eines Dispatch-Monitors einen letzten zugeteilten überwachten Thread, der durch einen Prozessor zugeteilt wird, wenn auf der Grundlage des Interrupts festgestellt wird, dass sich der Prozessor im Leerlauf befindet. Zudem stellt bei einem Prozessblock 806 der Prozess 850 eine Prozessoraffinität des letzten zugeteilten überwachten Threads so ein, dass der letzte zugeteilte überwachte Thread nur auf dem Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können. Bei einem Prozessblock 858 erhält der Prozess 850 durch den Call-Stack des letzten zugeteilten überwachten Threads weiter einen Ausführungskontext für den letzten zugeteilten überwachten Thread. Bei einem Prozessblock 860 stellt der Prozess 850 zudem der Prozessoraffinität des letzten zugeteilten überwachten Threads wieder her, nachdem der Call-Stack des letzten zugeteilten, überwachten Threads abgerufen wurde. Bei einem Prozessblock 864 zeichnet der Prozess 850 den Call-Stack für den letzten zugeteilten überwachten Thread auf. Die Aufzeichnung kann die Form eines Berichts haben.
Der hier beschriebene Prozess kann in einem oder mehreren Universal- oder Spezial-Mikroprozessoren realisiert werden. Derartige Mikroprozessoren führen Anweisungen entweder assembliert, compiliert oder auf Maschinenebene aus, um die Prozesse auszuführen. Diese Anweisungen können von Durchschnittsfachleuten geschrieben werden, die die Beschreibung der Figuren befolgen, die den Prozessen entsprechen und auf einem computerlesbaren Medium gespeichert bzw. auf ein solches übertragen werden. Die Anweisungen können außerdem mithilfe von Quellcode oder jedem anderen bekannten computerunterstützten Design-Werkzeug erstellt werden.
9 veranschaulicht ein Blockschaltbild eines Systems 900 gemäß einer Ausführungsform der vorliegenden Erfindung, das Sample von Leerlauftransitionen nimmt. Bei einer Ausführungsform ist das System 900 dafür geeignet, Programm-Code zu speichern und/oder auszuführen, und wird mithilfe eines Universalcomputers oder beliebiger anderer Hardware-Äquivalente realisiert. Das System 900 umfasst daher einen Prozessor 902 (der als ein „Mikroprozessor” bezeichnet werden kann), einen Speicher 912, z. B. Speicher mit wahlfreiem Zugriff (random access memory, „RAM”) und/oder Nur-Lese-Speicher (read only memory, „ROM”), den Profiler 104 sowie verschiedene Eingabe-/Ausgabeeinheiten 904.
Der Prozessor 902 ist mit dem Speicher 912 entweder direkt oder indirekt durch einen Systembus verbunden. Der Speicher 912 kann lokalen Speicher umfassen, der während der tatsächlichen Ausführung des Programm-Codes genutzt wird, Massenspeicher und/oder Cache-Speicher, in denen mindestens ein Teil des Programm-Codes vorübergehend gespeichert wird, damit Code bei der Ausführung weniger häufig aus dem Massenspeicher abgerufen werden muss.
Die Eingabe-/Ausgabe-Einheiten 904 können mit dem System 900 direkt oder durch dazwischenliegende Eingabe-/Ausgabe-Controller verbunden sein. Die Eingabe-/Ausgabe-Einheiten 904 können weiter eine Tastatur, ein Tastenfeld, eine Maus, ein Mikrofon zum Erfassen von Sprachbefehlen, eine Zeigeeinheit sowie andere Benutzereingabeeinheiten enthalten, die Fachleute erkennen werden. Die Eingabe-/Ausgabe-Einheiten 904 können weiter einen Empfänger, Sender, Lautsprecher, Bildschirm, Bildaufnahmesensor, biometrischen Sensor usw. enthalten. Darüber hinaus können die Eingabe-/Ausgabe-Einheiten 904 Speichereinheiten wie beispielsweise ein Bandlaufwerk, ein Diskettenlaufwerk, ein Festplattenlaufwerk, ein Compact Disk(„CD”)-Laufwerk, ein Digital Video Disk(„DVD”)-Laufwerk usw. enthalten.
Netzwerkadapter können ebenfalls mit dem System 900 verbunden sein, um das System 900 dazu in die Lage zu versetzen, mit anderen Systemen, Remote-Druckern oder Speichereinheiten durch dazwischengeschaltete private oder öffentliche Netzwerke verbunden zu werden. Modems, Kabelmodems und Netzwerkkarten sind nur einige der aktuell zur Verfügung stehenden Arten von Netzwerkadaptern.
Es sollte beachtet werden, dass das hier beschriebene Verfahren und System die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform oder einer Ausführungsform annehmen kann, die sowohl Hardware- als auch Software-Elemente enthält. Wenn Software zur Realisierung des Verfahrens oder Systems verwendet wird, kann die Software Folgendes enthalten, ohne aber darauf beschränkt zu sein: Firmware, residente Software, Mikrocode usw. Obwohl bei der veranschaulichten Ausführungsform aus 9 nur ein Mikroprozessor ausdrücklich gezeigt wird, kann das System mehr als einen Mikroprozessor aufweisen.
Jede der hier beschriebenen Konfigurationen kann mit einer virtuellen Maschine verwendet werden. Eine virtuelle Maschine kann dafür konfiguriert sein, den Aufrufstatus zu verfolgen und diesen Status zurückzugeben, wobei an eine von einer virtuellen Maschine unterstützte Schnittstelle verwiesen wird, um Call-Stacks zurückzugeben. Beispielsweise können durch Trace-Daten Informationen über die Ausführung von Threads gewonnen werden. Diese Informationen können Call-Stacks-Daten enthalten, die von Call-Stacks stammen, die zu interessierenden Threads gehören. Es kann eine virtuelle Maschine verwendet werden, um die Call-Stack-Daten zu erhalten. Die virtuelle Maschine kann verschiedene Ansätze verwenden, um die Call-Stack-Daten zu erhalten. Es können beispielsweise Eintritts-/Austrittsereignisse, ein Anwendungs-Timer-Impuls oder „Instrumentierungs-Codes” verwendet werden, die Samples von den „instrumentierten Werten” nehmen. Ein ausgewählter Sampling-Thread kann einen Aufruf an die virtuelle Maschine senden, die Call-Stack-Daten abzurufen. Der ausgewählte Sampling-Thread kann den Aufruf an die virtuelle Maschine mithilfe einer Virtual Machine Tool Interface („Virtual Maschine-Werkzeug-Schnittstelle”) ausführen. Die Virtual Machine Tool Interface kann Call-Stack-Daten an den Sampling-Thread zurückgeben oder kann die Call-Stack-Daten in einem Arbeitsbereich speichern. Die erhaltenen Daten können zur späteren Analyse in einen Baum eingefügt werden.
Wie Fachleute verstehen werden, können Aspekte der vorliegenden Erfindung als ein System, Verfahren oder Computerprogrammprodukt verkörpert sein. Dementsprechend können Aspekte der vorliegenden Erfindung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (eingeschlossen Firmware, speicherresidente Software, Mikrocode usw.) annehmen oder die einer Ausführungsform, bei der Software- und Hardwareaspekte kombiniert werden, die hier alle allgemein als „Schaltung”, „Modul” oder „System” bezeichnet werden sollen. Aspekte der vorliegenden Erfindung können außerdem die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien mit in dem Medium verkörperten computerlesbaren Programm-Code verkörpert ist.
Es kann eine beliebige Kombination von einem oder mehreren computerlesbaren Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, aber ohne darauf beschränkt zu sein, ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, eine derartige Vorrichtung oder Einheit oder jede beliebige Kombination von diesen sein. Als spezifischere Beispiele (eine nicht erschöpfende Liste) für das computerlesbare Speichermedium könnten die folgenden aufgeführt werden: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer, programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact Disc-Nur-Lese-Speicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination des Vorstehenden. Im Zusammenhang dieses Dokuments kann ein computerlesbares Speichermedium ein beliebiges physisches Medium sein, das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit enthalten oder speichern kann.
Ein computerlesbares Signalmedium kann unter anderem ein verbreitetes Datensignal mit in diesem verkörperten computerlesbaren Programm-Code sein, zum Beispiel im Basisband oder als Teil einer Trägerwelle. Ein solches verbreitetes Signal kann verschiedene Formen annehmen, unter anderem, aber ohne darauf beschränkt zu sein, eine elektromagnetische oder optische Form oder eine beliebige Kombination aus diesen. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm für die Nutzung durch ein Anweisungen ausführendes System, eine solche Vorrichtung oder Einheit oder für die Nutzung in Verbindung mit einem Anweisungen ausführenden System, einer solchen Vorrichtung oder Einheit übermitteln, verbreiten oder transportieren kann.
Auf einem computerlesbaren Medium verkörperter Programm-Code kann mithilfe jedes geeigneten Mediums übermittelt werden, darunter unter anderem, aber ohne darauf beschränkt zu sein, ein drahtloses oder drahtgebundenes Medium, Lichtwellenleiter-Kabel, HF (Hochfrequenz) usw. oder jede geeignete Kombination des Vorstehenden.
Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder Ähnliche sowie herkömmliche verfahrensorientierte Programmiersprachen wie beispielsweise die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programm-Code kann vollständig oder teilweise auf dem Computer des Benutzers, als ein eigenständiges Softwarepaket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernten Computer oder vollständig auf dem entfernten Computer oder Server ausgeführt werden. Bei dem letzteren Szenario kann der entfernte Computer mit dem Computer des Benutzers durch ein beliebiges Netzwerk, darunter ein Lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN) verbunden sein, oder es kann eine Verbindung mit einem externen Computer hergestellt werden (zum Beispiel mithilfe eines Internetdienstanbieters über das Internet).
Aspekte der vorliegenden Erfindung werden unten mit Bezug auf Flussdiagramme und/oder Blockschaltbilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Flussdiagramme und/oder Blockschaltbilder sowie Kombinationen von Blöcken in den Flussdiagrammen und/oder Blockschaltbildern durch Computerprogrammanweisungen realisiert werden können. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung zugeführt werden, so dass der Prozessor und die Anweisungen eine Maschine bereitstellen, die Funktionen und Handlungen realisiert, die in dem Flussdiagramm bzw. den Flussdiagrammen oder dem Blockschaltbild bzw. den Blockschaltbildern hier spezifiziert sind. Der „Prozessor” eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung kann hier als ein „Mikroprozessor” bezeichnet werden. Der Begriff „Mikroprozessor” sollte jedoch nicht als auf eine zentrale Recheneinheit mit einem einzigen Chip oder eine beliebige andere bestimmte Art von programmierbarer Datenverarbeitungsvorrichtung beschränkt aufgefasst werden, außer wenn dieses ausdrücklich so angegeben ist.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Weise funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen ein Erzeugnis samt der Anweisungen herstellen, mithilfe derer die in dem Block oder den Blöcken des Flussdiagramms und/oder Blockschaltbilds spezifizierte Funktion/Handlung ausgeführt wird. Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder den anderen Einheiten auszuführenden Betriebsschritten zu bewirken, um einen computerimplementierten Prozess zu schaffen, so dass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zur Realisierung der in dem Block oder den Blöcken des Flussdiagramms und/oder Blockschaltbilds spezifizierten Funktionen/Handlungen bereitstellen.
Das Flussdiagramm und die Blockschaltbilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In dieser Beziehung kann jeder Block in dem Flussdiagramm oder den Blockschaltbildern ein Modul, Segment oder einen Codeabschnitt enthalten, das/der eine oder mehrere ausführbare Anweisungen zur Realisierung der spezifizierten Logikfunktion(en) umfasst. Es sollte auch beachtet werden, dass bei einigen alternativen Realisierungen die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten können. Zum Beispiel können zwei aufeinander folgend dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können in Abhängigkeit von der betreffenden Funktionalität manchmal in der umgekehrten Reihenfolge ausgeführt werden. Es ist ebenfalls zu beachten, dass jeder Block der Blockschaltbilder und/oder des Flussdiagramms sowie Blockkombinationen in den Blockschaltbildern und/oder dem Flussdiagramm durch hardwarebasierte Spezialsysteme, die die spezifizierten Funktionen oder Handlungen ausführen, oder Kombinationen von Spezialhardware und Computeranweisungen realisiert werden können.
Wird in dieser Beschreibung auf „eine Ausführungsform” oder Ähnliches Bezug genommen, so heißt das, dass ein bestimmtes in Verbindung mit der Ausführungsform beschriebenes Merkmal, eine bestimmte derartige Struktur und/oder eine bestimmte derartige Eigenschaft in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Daher können in dieser gesamten Beschreibung die Formulierung „bei einer Ausführungsform” sowie ähnliche Begriffe sich alle auf dieselbe Ausführungsform beziehen, obwohl dies nicht notwendigerweise der Fall ist. Darüber hinaus können die beschriebenen Merkmale, Strukturen oder Eigenschaften der Erfindung auf jede geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden. Dementsprechend können, selbst wenn anfänglich beansprucht wird, dass Merkmale in bestimmten Kombinationen auftreten, in einigen Fällen ein oder mehrere Merkmale aus der Kombination herausgenommen werden, und die beanspruchte Kombination kann in eine Unterkombination oder eine Abänderung einer Unterkombination übergeleitet werden.
Obwohl die Vorrichtung und das Verfahren im Hinblick auf die Ausführungsformen beschrieben wurden, die gegenwärtig als die praktikabelsten und bevorzugten angesehen werden, versteht es sich, dass die Offenbarung nicht auf die offenbarten Ausführungsformen beschränkt sein muss. Die Offenbarung soll verschiedene Abwandlungen und ähnliche Anordnungen abdecken, die in dem Sinn und Schutzumfang der Ansprüche enthalten sind, wobei deren Schutzumfang die umfassendste Interpretation eingeräumt werden sollte, um alle derartigen Abwandlungen und ähnliche Strukturen zu umfassen. Die vorliegende Offenbarung enthält jegliche und alle Ausführungsformen der folgenden Ansprüche.

Claims

System (100) zum Anwendungs-Profiling von auf mehrern Prozessoren (112, 114, 116) ablaufenden Threads, das Folgendes aufweist: einen Prozessor aus den mehreren Prozessoren (112, 114, 116) zum Erstellen eines Sample auf der Grundlage eines Ereignisses mithilfe eines Sampler-Thread; ein Betriebssystem (106) zum (i) Erkennen, mithilfe eines Zuteilungsmonitors, eines nächsten zuzuteilenden überwachten Thread, der einem aktuellen Prozessor zugeteilt wird, und (ii) zum Einstellen, mithilfe eines Schedulers, einer Prozessoraffinität des nächsten zuzuteilenden überwachten from_Idle-Thread, so dass der nächste zuzuteilende überwachte from_Idle-Thread nur auf dem Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können; einen Profiler (104), der die Prozessoraffinität des nächsten zuzuteilenden überwachten to_Idle-Thread festgelegt, so dass der nächste zuzuteilende überwachte to_Idle-Thread nur auf dem Prozessor läuft, ohne zu einem anderen Prozessor migrieren zu können, und wobei der Profiler (104) zusätzlich angepasst ist zum (i) Abrufen, mithilfe des Sampler-Thread, der so konfiguriert ist, dass er nur auf dem aktuellen Prozessor läuft, eines Call-Stack des nächsten zuzuteilenden überwachten Thread, nachdem die Prozessoraffinität des nächsten zuzuteilenden überwachten Thread auf den Prozessor eingestellt wurde, sodass ein Kontext des nächsten zuzuteilenden Thread festgestellt wird, und (ii) Wiederherstellen der Prozessoraffinität des nächsten zuzuteiltenden überwachten Thread, nachdem der Call-Stack des nächsten zuzuteiltenden überwachten Thread abgerufen wurde, und (iii) Aufzeichnen des Call-Stack des nächsten zuzuteilenden überwachten Thread für den nächsten zuzuteilenden überwachten Thread.
System nach Anspruch 1, wobei das Ereignis auf einem vorgegebenen Ereignis basiert.
System nach Anspruch 1, wobei das vorgegebene Ereignis Zeit-basiert ist.
System nach Anspruch 1, wobei das Ereignis auf einem Interrupt basiert.
System nach Anspruch 1, wobei der Profiler (104) ein Profil der Anwendung erstellt.
System (100) nach einem der vorhergehenden Ansprüche, das weiter ein Benachrichtigen eines Betriebssystems (106) nach dem Aufzeichnen des Call-Stack des nächsten zuzuteilenden überwachten Thread für den nächsten zuzuteilenden überwachten Thread aufweist, dass ein Sample fertig gestellt wurde.