-
HINTERGRUND
-
Die starke Zunahme an Mehrkernprozessoren und virtuellen Prozessoren hat zu der vermehrten Verwendung von virtuellem Speicher geführt. Virtueller Speicher stellt die Illusion eines zusammenhängenden Abschnitts von Speicher zu jedem Prozess, der auf den Prozessoren eines Systems arbeitet, zur Verfügung, aber der tatsächliche physikalische Speicher, der durch jeden Prozess verwendet wird, kann über einen physikalischen Speicher eines Systems verteilt sein. Diesbezüglich ist ein virtueller Speicher typischerweise in Seiten aufgeteilt, wobei jede Seite auf eine Stelle des physikalischen Speichers eines Systems abgebildet ist. Eine Seitentabelle kann dazu verwendet werden, die virtuelle Speicherseite eines Teils von Daten auf die entsprechende physikalische Adresse abzubilden, wo die Daten gespeicher werden. Um die Geschwindigkeit eines Umwandelns von virtuellen Speicherseiten zu entsprechenden physikalischen Adressen zu erhöhen, kann jeder Kern eines Prozessors einen Übersetzungspuffer bzw. Translation Lookaside Buffer (TLB) implementieren, der neuste Übersetzungen von virtuellen Speicherseiten zu physikalischen Speicheradressen speichert.
-
Wenn eine Seitenabbildung eines virtuellen Speichers in einer Seitentabelle modifiziert wird oder wenn Hypervisoren eine Gastseite von einem virtuellen Speicher einer virtuellen Maschine nicht abbilden oder auf andere Weise modifizieren, muss der TLB für jeden Verarbeitungskern entsprechend aktualisiert bzw. einem Update unterzogen werden. Bei einigen Szenarien wird dies durch Senden einer Unterbrechung erreicht, die als TLB-Shootdown-Unterbrechung bekannt sind, welche jeden vorherbestimmten Prozessorkern instruiert, eine software-definierte Liste von nicht abgebildeten Seiteneinträgen eines virtuellen Speichers zu überprüfen und diese Einträge von ihrem jeweiligen TLB zu entfernen. Die vorherbestimmten Prozessorkerne können den nicht abgebildeten Eintrag aus ihren jeweiligen TLB-Tabellen entfernen und ihre Beendigung zu dem initiierenden Prozessor des TLB-Sootdowns signalisieren. Die OS-Software auf dem initiierenden Prozessor muss warten, bis alle Antworten zurückgebracht worden sind, bevor eine weitere Verarbeitung wiederaufgenommen werden kann. Ebenso muss ein empfangender Prozessor die TLB-Shootdown-Anfrage beenden, bevor er eine weitere Verarbeitung wiederaufnimmt.
-
In einer virtuialisierten Umgebung können Sende- und Empfangsuntzerbrechungen, wie beispielsweise TLB-Shootdown-Anfragen, zeitaufwändig sein, da eine Kommunikation zwischen physikalischen Prozessoren und virtuellen Prozessoren die Intervention des Hypervisors erfordert. Weiterhin können virtuelle Prozessoren offline sein (z.B. ausgeplant bzw. umdisponiert durch den Hypervisor oder die physikalische CPU kann angehalten sein), um dadurch zu veranlassen, dass die TLB-Shootdown-Bestätigung von jenen virtuellen Prozessoren verzögert wird. In Systemen mit einer großen Anzahl von virtuellen Prozessoren können diese Verzögerungen mehr werden, und zwar manchmal superlinear, was in signifikanten Leistungsreduktionen resultiert.
-
Dokument
US 2006 / 0 026 359 A1 offenbart ein Multiprozessorsystem und -verfahren bei dem mehrere Speicherplätze zum Speichern von TLB-Shootdown-Daten jeweils für mehrere Prozessoren verwendet werden.
-
Dokument
US 2016 / 0 041 922 A1 offenbart einen Prozessor, der einen Translation-Lookaside-Buffer (TLB) und ein Abbildungsmodul beinhaltet.
-
ZUSAMMENFASSUNG
-
Die Erfindung ist durch die unabhängigen Patentansprüche definiert. Verschiedene Ausführungsformen innerhalb der Offenbarung beziehen sich allgemein auf ein Verarbeiten von TLB-Shootdown-Anfragen. Ein Aspekt enthält ein Verfahren zum Dirigieren und Verfolgen von TLB-Shootdowns innerhalb von Hardware. Diesbezüglich können ein oder mehrere Prozessoren, die einen oder mehrere Prozessorkerne umfassen, bestimmen, dass ein auf einem Verarbeitungskern ausführender Prozess veranlasst, dass eine oder mehrere Seiten eines virtuellen Speichers von einem oder mehreren zuvor in Verbindung stehenden physikalischen Speicheradressen getrennt werden. Der Verarbeitungskern, der diesen Prozess ausführt, der die Trennung veranlasste, kann eine TLB-Shootdown-Anfrage erzeugen. Der Verarbeitungskern kann die TLB-Shootdown-Anfrage zu den anderen Kernen senden. Die TLB-Shootdown-Anfrage kann Identifikationsinformation, eine Shootdown-Adresse, die die getrennte Seite oder die getrennten Seiten eines virtuellen Speichers anzeigt, die von den jeweiligen TLBs der anderen Kerne geleert werden muss oder müssen, und eine Benachrichtigungsadresse, die anzeigt, wo die anderen Kerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, enthalten.
-
Bei einigen Beispielen kann das Verfahren weiterhin ein Empfangen von Bestätigungen von den anderen Kernen auf ihre Beendigung der TLB-Shootdown-Anfrage hin enthalten. Die Bestätigungen können bei der Benachrichtigungsadresse empfangen werden. Der eine oder die mehreren Prozessoren kann oder können eine oder mehrere virtuelle Maschinen ausführen, wobei die virtuellen Maschinen einen oder mehrere virtuelle Computerprozessoren enthalten. Der Prozess kann ein erster Prozess sein, der eine der einen oder den mehreren virtuellen Maschinen ausführt.
-
Bei einigen Beispielen kann das Verfahren weiterhin ein Bestimmen durch eine Leistungs-Managementeinheit enthalten, ob ein erster Kern, der die TLB-Shootdown-Anfrage empfing, in einem Kleinleistungszustand ist, und in dem Fall, in welchem der erste in einem Kleinleistungszustand ist, ein Bestätigen der TLB-Shootdown-Anfrage durch die Leistungs-Managementeinheit.
-
Ein weiterer Aspekt enthält ein System zum Dirigieren und Verfolgen von TLB-Shootdowns innerhalb von Hardware. Das System kann eine oder mehrere Computervorrichtungen umfassen, die einen oder mehrere Kerne umfassen. Diesbezüglich kann der eine oder können die mehreren Priozessoren konfiguriert sein, um zu bestimmen, dass ein Prozess, der auf einem von dem einen oder den mehreren Verarbeitungskernen ausführt, veranlasst, dass eine oder mehrere Seiten eines virtuellen Speichers von einem oder mehreren zuvor in Verbindung stehenden physikalischen Speicheradressen getrennt wird oder werden. Der Vderarbeitungskern, der den Prozess ausführt, der die Trennung veranlasste, kann konfiguriert sein, um eine TLB-Shootdown-Anfrage zu erzeugen. Der Verarbeitungskern kann weiterhin konfiguriert sein, um die TLB-Shootdown-Anfrage zu den anderen Kernen zu senden. Die TLB-Shootdown-Anfrage kann Identifikationsinformation, eine Shootdown-Adresse, die die getrennte Seite oder die getrennten Seiten eines virtuellen Speichers anzeigt, die von den jeweiligen TLBs der anderen Kerne geleert werden muss oder müssen, und eine Benachrichtigungsadresse, die anzeigt, wo die anderen Kerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, enthalten.
-
Figurenliste
-
Die vorliegende Technologie wird anhand eines Beispiels und nicht anhand einer Beschränkung in den Figuren der beigefügten Zeichnungen dargestellt, in welchen gleiche Bezugszeichen sich auf ähnlich Elemente beziehen, einschließlich:
- 1 zeigt ein System gemäß Aspekten der Offenbarung.
- 2 zeigt ein System, das mehrere virtuelle Maschinen ausführt, gemäß Aspekten der Offenbarung.
- 3 zeigt ein System, das eine virtuelle Maschine auf mehreren Kernen ausführt, gemäß Aspekten der Offenbarung.
- 4 ist ein Ablaufdiagramm gemäß Ausführungsformen der Offenbarung.
- 5 ist ein Ablaufdiagramm gemäß Ausführungsformen der Offenbarung.
-
DETAILLIERTE BESCHREIBUNG
-
ÜBERBLICK
-
Die Technologie bezieht sich auf ein System, ein Verfahren und ein computerlesbares Medium zum effizienten Verarbeiten von Übersetzungspuffer- bzw. Translation Lookaside Buffer- (TLB-)Shootdowns. In herkömmlichen Umgebungen eines mehrkernprozessors und einer virtuellen Maschine (VM) werden TLB-Shootdowns von einem ersten Kern gesendet und durch jeden anderen Kern (oder eine Untergruppe von Kernen) auf einem Prozessor empfangen. Jeder emfangende Kern muss dann seinen jeweiligen TLB überprüfen, um zu bestimmen, ob der TLB die virtuelle Seite oder die virtuellen Seiten enthält, die der TLB-Shootdown derart anzeigt, dass sie eine Entfernung benötigt oder benötigen. Auf ein Bestimmen hin, dass der TLB-Shootdown ein Erfolg war, oder nicht nötig, müssen die emfangenden Kerne individuell eine Beendigung des TLB-Shootdown zu dem sendenden Kern bestätigen. Dies kann ein zeit- und ressourcenintensiver Prozess sein, und zwar insbesondere dann, wenn der TLB-Shootdown durch einen Prozesvorgang in einer virtuellen Maschine initiiert wird, wodurch eine Kommunikation durch mehrere Schichten von Software ein weiteres Verarbeiten durch alle der Kerne signifikant verzögern kann.
-
Gemäß der vorliegenden Offenbarung können die Verarbeitungsressourcen, die TLB-Shootdowns beenden mussten, durch Verwenden einer vollständigen Hardwareimplementierung zum Dirigieren und Verfolgen von TLB-Shootdowns auf nur diejenigen Kerne reduziert werden, die mit einem TLB in Verbindung gebracht sind, der wahrscheinlich eine Entfernung des Seite oder der Seiten eines virtuellen Speichers erfordert. Beispielsweise kann, wenn ein Prozess, der auf einem oder mehreren Verarbeitungskernen ausführt, veranlasst, dass eine oder mehrere Seiten eines virtuellen Speichers von einer oder mehreren zuvor in Verbindung stehenden physikalischen Speicheradressen getrennt wird oder werden, eine TLB-Shootdown-Anfrage duch den Kern erzeugt werden kann, der die Trennung veranlasste. Die TLB-Shootdown-Anfrage kann Identifikationsinformation, eine Shootdown-Adresse, die die getrennte Seite oder die getrennten Seiten eines virtuellen Speichers anzeigt, die von den jeweiligen TLBs der anderen Kerne geleert werden muss oder müssen, und eine Benachrichtigungsadresse, die anzeigt, wo die anderen Kerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, enthalten.
-
Die Identifikationsinformation kann einen Identifizierer für jed VM, jede VCPU innerhalb der VMs, jeden Prozessorkern enthalten, und jeder innerhalb einer VCPU und/oder eines Prozessorkern ausgeführte Prozess kann einen Identifizierer enthalten. Bei bestimmten Ausführungsformen, wie beispielsweise innerhalb eines x86-Systems, kann die Identifkationsinformation eine oder mehrere hochentwickelte programmierbare Unterbrechungssteuerungs-IDs (APICIDs), einen ID für einen virtuellen Prozessor (VPID) und einen Prozesskontext-Identifizierer (PCID) enthalten. APICIDs können durch eine Softwareanwendung, wie beispielsweise ein Betriebssystem, verfolgt und zur Verfügung gestellt werden. Beispielsweise kann jedem Kern eines Systems ein APICID durch ein Betriebssystem oder durch die Hardware selbst zugeordnet werden. Das Betriebssystem kann verfolgen, welche Kerne einen bestimmten Prozess ausführen, und die APICIDs von diesen Kernen bestimmen. In dem Fall, in welchem der Prozess auf einer virtuellen Maschine (VM) ausführt, kann das Betriebssystem eine Tabelle verwenden, um die virtuellen Prozessoren (VCPUs) der VM, die den bestimmten Prozess ausführen, auf den physikalischen Kern oder die physikalischen Kerne abzubilden, die die VM ausführen. Die APICIDs können dieser physikalische Kern oder diese physikalische Kerne sein, die die VM ausführen.
-
IDs eines virtuellen Prozessors können sowohl logischen Prozessoren einer VM als auch physikalischen Kernen zugeordnet sein. Beispielsweise kann, wenn der Prozess außerhalb einer VM ausführt, diesem physikalischen Kern ein VPID-Wert von 0 zugeordnet sein. In dem Fall, in welchem der Prozess in einer VM arbeitet, kann der Hypervisor, der die VM steuert, den VPID-Wert zuordnen.
-
Ein Prozesskontext-Identifizierer (PCID) kann jedem Prozess zugeordnet werden, der ausgegführt wird. Diesbezüglich können die PCIDs jedes Prozesses bestimmten TLB-Einträgen, die mit einem jeweiligen Prozess in Verbindung stehen, zugeordnet werden. Für den Prozess, der die TLB-Shootdown-Anfrage anfragte, kann der PCID bestimmt werden. Zusammen können die APICIDs, der VPID und der PCID, die mit dem Prozess in Verbindung stehen, der den TLB-Shootdown anfragte, als die Identifikationsinformation angesehen werden.
-
Eine TLB-Shootdown-Anfrage kann zu allen Kernen gesendet werden, die auf dem System arbeiten. Wie es hierin beschrieben ist, kann die TLB-Shootdown-Anfrage die Identifikationsinformation, eine Shootdown-Adresse und eine Benachrichtigungsadresse enthalten.
-
Für jeden Kern, der die TLB-Shootdown-Anfrage empfängt, kann ein Vergleich durchgeführt werden zwischen der Identifikationsinformation eines empfangenden Kerns und der Identifikationsinformation, die in der TLB-Shootdown-Anfrage enthalten ist. Diesbezüglich kann, wenn die Identifikationsinformation eines empfangenden Kerns nicht mit der in der TLB-Shootdown-Anfrage enthaltenen Identifiaktionsinformation übereinstimmt, die TLB-Shootdown-Anfrage ignoriert werden, und zwar durch einen Hardware-Mechanismus und ohne die Ausführung der Anweisungsstroms der CPU zu beeinflussen. Sonst kann der emfangende Kern seinen jeweiligen TLB überprüfen, um zu bestimmen, ob er die Shootdown-Adresse enthält, und wenn es so ist, wird er diese Adresse für ungültig erklären. Auf eine Beendigung der Ungültigkeitserklärung hin oder dann, wenn die Shootdown-Adresse nicht innerhalb des TLB des empfangenden Kerns ist, oder wenn die Ungültigkeitserklärung ignoriert wird, kann der empfangende Kern eine Ungültigkeitserklärungsbestätigung zu der benachrichtigungsadresse senden und sein normalen Funktionen wiederaufnehmen, wie beispielsweise ein Fortfahren mit Prozessanwendungen.
-
Der sendende Kern kann die Anzahl von vom empfangenden Kern empfangenen Bestätigungen verfolgen. Diesbezühglich kann der sendende Kern die Anzahl von bei der Benachrichtigungsadresse empfangenen Bestätigungen verfolgen, bis alle der empfangenden Kerne, von welchen er erwartet, dass sie die TLB-Shootdown-Anfrage bestätigen, dies tun. Bei einigen Ausführungsformen kann der sendende Kern einen Betrieb fortsetzen, sobald er die TLB-Shootdown-Anfrage sendet. Um den Zustand der TLB-Shootdown-Anfrage zu überwachen, kann Software, wie beispielsweise das Betriebssystem, sicherstellen, dass alle Bestätigungen empfangen worden sind.
-
Die hierin beschriebenen Merkmale können zulassen, dass ein System TLB-Shootdown-Anfragen effizienter verarbeitet. Diesbezüglich können TLB-Shootdown-Anfragen durch Prozessorkerne ignoriert werden, die keinen Prozess ausführen, der den TLB-Shootdown veranlasste. Zusätzlich kann der Prozessorkern, der den TLB-Shootdown sendete, Bestätigungen empfangen, dass der TLB-Shootdown beendet wurde, oder muss Bestätigungen überhaupt nicht verfolgen, was für den Prozessorkern, der den TLB-Shootdown sendete, zulässt, dass er andere Operationen schneller fortsetzt.
-
BEISPIELHAFTE SYSTEME
-
1 stellt ein System 100 dar, bei welchem TLB-Sootdowns durchgeführt werden können. Diesbezüglich enthält das System wenigstens einen Prozessor 103. Das System 100 enthält auch eine Seitentabelle 131, einen physikalischen Speicher 141, einen sekundären Speicher 151 und eine Leistungs-Managementeinheit 161.
-
Der physikalische Speicher 141 und der sekundäre Speicher 151 können Information speichern, auf die durch den einen oder die mehreren Prozessoren 103 zugreifbar ist, einschlißlich Anweisungen (nicht gezeigt), die durch den Prozessor 103 ausgeführt werden können. Der physikalische und der sekundäre Speicher können auch Daten (nicht gezeigt) enthalten, die durch den Prozessor 103 ausgelesen, manipuliert oder gespeichert werden können. Der physikalische und der sekundäre Speicher können von irgendeinem nichtflüchtigen Typ sein, der Information speichern kann, auf die durch den Prozessor zugreifbar ist, wie beispielsweise eine Festplatte, eine Speicherkarte, ein ROM, ein RAM, eine DVD, ein CD-ROM, beschreibbare und Nurlesespeicher.
-
Die innerhalb des physikalischen und des sekundären Speichers gespeicherten Anweisungen können irgendeine Gruppe von Anweisungen sein, um durch den Prozessor direkt ausgeführt zu werden, wie beispielsweise Maschinencode, oder indirekt, wie beispielsweise Skripte. Diesbezüglich können die Ausdrücke „Anweisungen“, „Anwendung“, „Schritte“ und „Programme“ hierin austauschbar verwendet werden. Die Anweisungen können im Objektcodeformat zur direkten Verarbeitung durch einen Prozessor gespeichert werden, oder in einer anderen Computervorrichtungssprache, einschließlich Skripten oder Sammlungen von unabhängigen Quellcodemodulen, die auf eine Anforderung hin interpretiert oder im Voraus kompiliert werden. Funktionen, Verfahren und Routinen der Anweisungen werden nachfolgend detaillierter erklärt.
-
Die innerhalb des physikalischen und des sekundären Speichers gespeicherten Daten können durch den Prozessor 103 gemäß den Anweisungen ausgelesen, gespeichert und modifiziert werden. Beispielsweise können, obwohl der hierin beschriebene Gegenstand nicht durch irgendeine bestimmte Datenstruktur beschränkt ist, die Daten in Computerregistern, in einer relationalen Datenbank als eine Tabelle mit vielen unterschiedlichen Feldern und Datensätzen oder XML-Dokumente gespeichert sein. Die Daten können auch in irgendeinem computervorrichtungslesbaren Format formatiert sein, wie beispielsweise, aber nicht darauf beschränkt, in binären Werten, ASCII oder Unicode. Darüberhinaus können die Daten irgendeine Information umfassen, die ausreichend ist, um die relevante Information zu identifizieren, wie beispielsweise Zahlen, beschreibenden Text, proprietäre bzw.ausschließliche Codes, Zeiger, Referenzen zu Daten, die in anderen Speichern gespeichert sind, wie beispielsweise bei anderen Netzwerkstellen, oder Information, die durch eine Funktion verwendet wird, um die relevanten Daten zu berechnen.
-
Der Prozessor 103 kann irgendein herkömmlicher Prozessor sein, wie beispielsweise Prozessoren von Intel Corporation oder Advanced Micro Devices. Alternativ dazu kann der Prozessor eine festgeschaltete bzw. zweckbestimmte Steuerung sein, wie beispielsweise ein anwendungsspezifischer integrierter Schaltkreis (ASIC), ein feldprogrammierbarer Gate Array (FPGA), etc. Zusätzlich kann der Prozessor 103 mehrere Prozessoren, Mehrkernprozessoren oder eine Kombination davon enthalten. Obwohl in 1 nur ein Prozessor 103 gezeigt ist, würde ein Fachmann auf dem Gebiet erkennen, dass innerhalb des Systems 100 einige Prozessoren existieren können. Demgemäß werden Bezugnahmen auf einen Prozessor derart verstanden, dass sie Bezugnahmen auf eine Sammlung von Prozssoren oder eine zweckbestimmte Logik enthalten, die parallel arbeiten können oder nicht.
-
Der Prozessor 103 kann einen oder mehrere Kerne 105-111 enthalten. Jeder Kern kann Programmanweisungen unabhängig von den anderen Kernen ausführen, um dadurch eine Mehrfachverarbeitung zu ermöglichen. Obwohl es nicht gezeigt ist, kann jeder Kern einen Cache enthalten oder ein einziger Cache kann zugehörig zu allen Kernen sein.
-
Das System enthält auch wenigstens eine Seitentabelle 131. Die Seitentabelle 131 kann verwendet werden, um die virtuelle Speicherseite eines Teils von Daten, die innerhalb des Prozessors 103 in einem Cache gespeichert sind, zu der entsprechenden physikalischen Adresse abzubilden, wo die Daten gespeichert sind, wie beispielsweise in dem physikalischen Speicher 141 oder dem sekundären Speicher 151. Obwohl die Seitentabelle 131 außerhalb des Prozessors 103 gezeigt ist, kann die Seitentabelle innerhalb des Caches des Prozessors 103 oder dem dem physikalischen 141 oder dem sekundären Speicher 151 gespeichert sein.
-
Um die Geschwindigkeit eines Umwandelns von virtuellen Speicherseiten zu entsprechenden physikalischen Adressen zu erhöhen, kann jeder Kern 105-111 eines Prozessors eine Übersetzungspuffer bzw. Translation Lookaside Buffer (TLB) 121-127 enthalten, der neueste Übersetzungen von virtuellen Speicherseiten zu physikalischen Speicheradressen speichert.
-
Das System 100 kann eine Leistungs-Managementeinheit 161 enthalten. Die Leistungs-Managementeinheit kann den Leistungszustand jedes Kerns innerhalb des Prozessors 103 verfolgen. Solche Zustände können einen „Ein“-Zustand, einen „Aus“-Zustand oder Bereiche von Leistungszuständen zwischen dem „Ein“- und dem „Aus“-Zustand enthalten. Wie es nachfolgend detailliert beschrieben ist, kann die Leistungs-Managementeinheit programmiert sein, um im Auftrag von jedem Kern zu kommunizieren.
-
Wie es in 2 dargestellt ist, kann das System 100 konfiguriert sein, um eine oder mehrere virtuelle Maschinen (VMs) 201-205 zu betreiben. Diesbezüglich kann ein Hypervisor 221 auf einem Host 231 installiert sein, der auf dem Prozessor 103 ausgeführt wird. In Betrieb kann der Host 231 ein Betriebssystem laufen lassen, das einen Hypervisor enthält, wie beispielsweise den Hypervisor 221, oder einen virtuellen Maschinenmanager (VMM). Bei einigen Ausführungsformen kann der Hypervisor 221 direkt auf dem Prozessor 103 ohne einen Host 231 arbeiten. Zu Zwecken dieser Anmeldung können der Hypervisor und der VMM austauschbar verwendet werden. Weiterhin würde ein Fachmann auf dem Gebiet erkennen, dass das Betriebssystem des Hosts 231 Linux, Windows™ oder irgendein anderes geeignetes Betriebssystem sein kann, das virtuelle Maschinen unterstützen kann.
-
Der Hypervisor kann jede VM so managen, dass es scheint, dass die VMs voneinander isoliert sind. Das bedeutet, dass jede VM 201, 203 und 205 glauben kann, dass sie eine unabhängige Mschine mit ihren eigenen Hardwareressourcen ist. Diesbezüglich kann der Hypervisor 221 den Zugriff von VMs auf die Ressourcen des Systems 100 (d.h. den Speicher, die Netzwerkschnittstellensteuerung, etc.) steuern. Der Hypervisor 221 kann ein Hardware-Visualisierungsschema implementieren, das Hardware-Ressourcen zu den VMs zuteilt, wie es nötig ist. Gemäß einigen Beispielsen ist der Prozessor 103 eine der Hardware-Ressourcen, mit welchen die VMs 201, 203 und 205 über den Hypervisor 221 interagieren.
-
Die VMs 201, 203 und 205 sind Software-Implementierungen eines Computers. Das bedeutet, dass die VMs 201, 203 und 205 ein Betriebssystem ausführen. Während in den Figuren nur drei VMs gezeigt sind, würde ein Fachmann auf dem Gebiet erkennen, dass irgendeine Anzahl von VMs durch das System 100 unterstützt werden kann. Das Betriebssystem der verschiedenen VMs 201, 203 und 205 kann dasselbe Betriebssystem wie der Host 231 sein, muss dies aber nicht notwendigerweise sein. Darüberhinaus kann das Betriebssystem jeder VM unterschiedlich von anderen VMs sein. beispielsweise kann der Host 231 ein auf Linux basierendes Betriebssystem laufenlassen, während VM 201 ein Windows™-Betriebssystem laufenlassen kann und VM 203 ein Solaris™- Betriebssystem laufenlassen kann. Die verschiedenen Kombinatihonen von Betriebssystemen würden einem Fachmann auf dem Gebiet ohne weiteres klar werden und werden hierin nicht detaillierter diskutiert. Bei einigen Ausführungsformen können VMs innerhalb anderer VMs verschachtelt sein. Diesbezüglich kann die VM 201 ein Host für eine andere Gast-VM spielen.
-
Jede VM kann ihre eigenen virtuellen zentralen Verarbeitungseinheiten (VCPUs) 211-215 enthalten. Obwohl die VMs der 2 mit nur einer einzigen VCPU gezeigt sind, können die VMs irgendeine Anzahl von VCPUs enthalten. Die VCPUs sind virtualisierte Prozessoren, die einem physikalischen Prozessor zugeordnet sind, wie beispielsweise einen Prozessorkern des Prozessors 103. Jede VCPU kann ihre eigene eindeutige Identifikation haben, die als ID eines virtuellen Prozessors (VPID) bekannt ist.
-
BEISPIELHAFTE VERFAHREN
-
Um TLB-Shootdown-Anfragen effizient zu verarbeiten, können TLB-Shootdowns durch Dirigieren und Verfolgen von TLB-Shootdowns zu nur denjenigen Kernen reduziert werden, die einem TLB zugehörig sind, der wahrscheinlich eine Entfernung der Seite oder der Seiten eines virtuellen Speichers erfordert. Beispielsweise können, wie es in 4 dargestellt ist, wenn ein Prozess, der auf einem oder mehreren Verarbeitungskernen ausführt, veranlasst, dass eine oder mehrere Seiten eines virtuellen Speichers von einer oder mehreren zuvor in Verbindung stehenden bzw. zugehörigen physikalischen Speicheradressen getrennt wird oder werden, eine TLB-Shootdown-Anfrage durch den Kern erzeugt werden, der die Trennung veranlasste, wie es im Block 401 gezeigt ist. Wie es zuvor beschrieben ist, kann die TLB-Shootdown-Anfrage Identifikationsinformation enthalten, die zulässt, dass jeder der empfangenden Kerne schnell bestimmt, ob ein Shootdown nötig ist, eine Shootdown-Adresse, die die Seite oder die Seiten des virtuellen Speichers anzeigt, die aus den jeweiligen TLBs geleert werden muss oder müssen, und eine Benachrichtigungsadresse, die anzeigt, wo die empfangenden Kerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können.
-
Die Identifikationsinformation kann einen Identifizierer für jede VM, jede VCPU innerhalb der VMs, jeden Prozessorkern und jeden innerhalb einer VCPU ausgeführten Prozess enthalten und/oder ein Prozessorkern kann einen Identifizierer enthalten. Bei bestimmten Ausführungsformen, wie beispielsweise innerhalb eines x86-Systems, kann die Identifikationsinformation eine oder mehrere IDs für hochentwickelte programmierbare Unterbrechungssteuerung (APICIDs), eine ID für einen virtuellen Prozessor (VPID) und einen Prozesskontext-Identifizierer (PCID) enthalten. Die APICIDs können durch eine Software-Anwendung verfolgt und zur Verfügung gestellt werden, wie beispielsweise das Betreibssystem des Hosts 231, wie es im Block 403 dargestellt ist. Beispielsweise kann jedem Kern eines Systems eine APICID durch ein Betriebssystem zugeordnet sein, wie beispielsweise das Betriebssystem, das auf dem Host 231 ausführt. Das Betriebssystem kann verfolgen, welche Kerne einen bestimmten Prozess ausführen, und die APICIDs von diesen Kernen bestimmen.
-
Um die APICIDs zu einer TLB-Shootdown-Anfrage zuzuordnen, kann eine Bestimmung diesbezüglich durchgeführt werden, ob der Prozess, der die Anfrage des TLB-Shootdowns initiierte, gerade auf einer VM (Gast) oder einem Host (real) ausgeführt wird, wie es im Block 404 gezeigt ist. In dem Fall, in welchem der Prozess auf einer VM arbeitet, kann das Betriebssystem eine Tabelle verwenden, um die virtuellen Prozessoren (VCPUs) der VM, die den bestimmten Prozess ausführen, zu dem physikalischen Kern oder deN physikalischen Kernen abzubilden, die die VM ausführen, wie es im Block 405 gezeigt ist. Die APICIDs von diesem physikalischen Kern oder diesen physikalischen Kernen, die die VM ausführen, können als die APICIDs der TLB-Shootdown-Anfrage zugeordnet werden. In dem Fall, in welchem der Prozess nicht in einer VM ausführt, wird die APICID die realen APICIDs sein, die den Prozess ausführen, wie es im Block 409 gezeigt ist.
-
Ein Beispiel eines Zuordnens einer APICID zu einer VCPU ist in 3 gezeigt. Diesbezüglich kann VM 201, die die VCPU 211 enthält, durch den Hypervisor 221 gesteuert werden, der wiederumn auf dem Host-Betriebssystem 231 installiert ist. Die VCPU 211 kann dem Kern 105 des Prozssors zu eienr ersten Zeit zugeordnet werden und zu einer anderen Zeit dem Kern 107 zugeordnet werden, wie es durch den Kasten 301 dargestellt ist. Das Host-Betriebssystem 231 kann eine Tabelle (nicht gezeigt) enthalten, die die APICID der VCPU 211 zu den APICIDs der Prozessorkerne 105 und 107 abbildet. Als solches kann, wenn ein erster Prozess, der auf der VM 201 ausführt, einen TLB-Shootdown anfragt, das Host-Betriebssystem die zwei zu den Prozessorkernen 105 und 107 gehörenden APICIDs zuordnen.
-
Wendet man sich wieder der 4 zu, kann der ID des virtuellen Prozessors zu sowohl logischen Prozssoren einer VM als auch physikalischen Kernen zugeordnet werden. Beispielsweise kann, wenn der Prozess gerade auf einem physikalischen Kern ausgeführt wird, diesem physikalischen Kern ein VPID-Wert von 0 zugeordnet werden, wie es im Block 411 gezeigt ist. In dem Fall, in welchem der Prozess auf einer VM arbeitet, kann der Hypervisor, der die VM steuert, den VPID-Wert zuordnen, wie es im Block 407 gezeigt ist. Diesbezüglich kann der VPID-Wert in der TLB-Shootdown-Anfrage der innerhalb der VM arbeitenden VCPU ignoriert werden, da dieser VPID-Wert sich ändern kann, wenn VMs hinzugefügt oder vom System 100 entfernt werden.
-
Ein Prozesskontext-Identifizierer (PCID) kann zu jedem Prozess zugeordnet werden, der ausgeführt wird. Ein Prozesskontext-Identifizierer stellt ein eindeutiges Tag zu jedem Prozess zur Verfügung, der durch einen Prozessor ausgeführt wird, einschließlich VCPUs. Diesbezüglich können die PCIDs jedes Prozesses zu bestimmten TLB-Einträgen zugeordnet werden, die zu einem jeweilgen Prozess gehören. Für den Prozess, der die TLB-Shootdown-Anfrage anfragte, kann der PCID durch den Prozessor bestimmt werden. Zusammen können die APICIDs, der VPID und der zu dem Prozess, der den TLB-Shootdown anfragte, gehörende PCID als die Identifikationsinformation angesehen werden.
-
Die Identifikationsinformation, die Shootdown-Adresse und die Benachrichtigungsadresse des TLB-Shootdowns können in einen Speicher, wie beispielsweise den physikalischen Speicher 141, als Tupel geschrieben werden oder können zu Registern (nicht gezeigt) im Prozessor 103 zugeordnet werden. Beispielsweise können in dem Fall einer x86-Prozessorarchitektur die Identifikationsinformation, die Shootdown-Adresse und die Benachrichtigungsadresse des TLB-Shootdowns in verschiedene Prozessorregister, wie beispielsweise die RDX-, RAX-, RCX- und RDI-Register, eingegeben werden. In einem Fall können die APICIDs in das RDX-Register eingegeben werden und können der VPID und PCIDs in die RDI-Register eingegeben werden, und zwar über einen Befehl eines Schreibens zum Modellieren eines spezifischen Registers (WRMSR).
-
Das RCX-Register kann codiert sein, um anzuzeigen, dass gerade ein Unterbrechungsbefehl (z.B. die TLB-Shootdown-Anfrage) gesendet wird. Beispielsweise kann in einem x86-System ein existierender RCX-Registerwert 0x830 sein und kann RDX das Zielortfeld (z.B. APICID) sein. Die existierenden RAX-Werte können wie folgt sein: Zielort in Kurzform: 00; Triggermode: 0; Level: 1; Zielortmode: 0 oder 1, um physikalisch oder logisch anzuzeigen. Diese Werte können durch Hinzufügen einer neuen Codierung zu „Leifermode“ und „Vektor“ modifiziert werden. Bespielsweise gilt „Liefermode = 010 (für SMI) und ist Vektor eine neuer Wert von nicht Null. Oder es gilt Liefermode = 100 (NMI) und Vektor ist eine neuer Wert von nicht Null. Die neue Codierung kann anzeigen, dass ein TLB-Shootdown durcgeführt wird. Zusätzlich können andere neue Werte in anderen Registern sein. Beispielsweise kann RDI ein erweitertes Zielortfeld (z.B. VPID und PCID) enthalten, kann RSI die Benchrichtigungsadresse enthalten und enthält RBX eine Shootdown-Adressencodierung. Andere Codierungen können auch verwendet werden, um anzuzeigen, dass ein TLB-Shootdown durchgeführt wird. Die Werte können in das RAX-Register eingegeben werden, sowie andere Register, und zwar über einen Befehl eines Schreibens zum Modellieren eines spezifischen Registers (WRMSR).
-
Der APICID kann codiert sein, um anzuzeigen, ob die TLB-Shootdown-Anfrage in einem logischen oder physikalischen Mode gesendet werden wird. Diesbezüglich wird der physikalische Mode separate TLB-Shootdown-Anfragen für jeden Kern im System erfordern. Beispielsweise enthält der Prozessor 103 vier Kerne, von welchen einer die TLB-Anfrage sendet. Als solches werden drei separate Shootdown-Anfragen zu jedem der anderen drei Kerne gesendet werden. Wenn der APICID in einem logischen Mode ist, wird den anderen drei Kernen allen dieselbe TLB-Shootdown-Anfrage gesendet werden.
-
Die Shootdown-Adresse kann in dem Tupel oder einer Registratur enthalten sein. Diesbezüglich kann die Shootdown-Adresse in das Tupel oder die Registratur codiert sein. Beispielsweise kann die Shootdown-Adresse als eine oder mehrere von einer Seitenadresse einer 4kb Seite (z.B. einer Adresse, die zu einer INVLPG-Anweisungscodierung passt), einer Startadresse und einer Anzahl von Seiten (z.B. codiert als log(num pages) oder als (num pages)) oder als eine Liste von Ungültigkeitserklärungsadressen codiert sein.
-
Eine TLB-Shootdown-Anfrage kann zu allen der Kerne gesendet werden, die auf dem System arbeiten, wie es im Block 417 gezeigt ist. Wie es beschrieben ist, kann die TLB-Shootdown-Anfrage die Identifikationsinformation, eine Shootdown-Adresse und eine Benachrichtigungsadresse enthalten. Bei einigen Ausführungsformen kann das Betriebssystem TLB-Shootdowns zu nur denjenigen Kernen dirigieren, die zu einem TLB gehören, der wahrscheinlcih eine Entfernung einer Seite oder von Seiten eines virtuellen Speichers erfordert. Als solches kann das OS den TLB-Shootdown zu einer Untergruppe der Kerne dirigieren.
-
Wendet man sich nun der 5 zu, kann in jedem Kern, der die TLB-Shootdown-Anfrage empfängt, ein Vergleich zwischen der Identifikationsinformation des empfangenden Kerns und der in der TLB-Shootdown-Anfrage enthaltenen Identifikationsinformation durchgeführt werden, wie es im Block 501 gezeigt ist. Diesbezüglich kann, wenn die Identifikationsinformation des empfangenden Kerns nicht mit der in der TLB-Shootdown-Anfrage enthaltenen Identifikationsinformation übereinstimmt, die TLB-Shootdown-Anfrage ignoriert werden, wie es im Block 503 gezeigt ist. Sonst kann der empfangende Kern seine jeweilige TLB überprüfen, um zu bestimmen, ob sie die Shootdown-Adresse enthält, und wenn es so ist, wird er diese Adresse für ungültig erklären, wie es im Block 505 gezeigt ist.
-
Auf eine Beendigung der Ungültigkeitserklärung hin oder wenn die Shootdown-Adresse nicht innerhalb der TLB des empfangenden Kerns ist, kann der empfangende Kern eine Ungültigkeitserklärungsbestätigung zu der Benachrichtigungsadressse senden, wie es im Block 507 gezeigt ist. Eine Bestätigung kann auch gesendet werden, wenn die Identifikationsinformation des empfangenden Kerns nicht mit der in der TLB-Shootdown-Anfrage enthaltenen Identifikationsinformation übereinstimmt. Der empfangende Kern kann normale Funktionen wiederaufnehmen, wie beispielsweise ein Fortfahren zu Prozessanwendungen, und zwar auf eine Beendigung des TLB-Shootdowns hin. Bei einigen Beispielen kann eine Bestätigung durch alle Kerne gesendet werden, die den TLB-Shootdown empfangen, und zwar selbst von empfangenden Kernen, die den TLB-Shootdown ignorieren. Bei anderen Beispielen werden nur die Kerne, die dem Shootdown Folge leisten, die Bestätigung senden.
-
Bei einigen Beispielen kann eine Leistungs-Managementeinheit eines Prozessors eine Beendigung eines TLB-Shootdowns bestätigen. Diesbezüglich kann ein Kern seine TLB auf ein Schalten zu einem Leistungszustand unter einer bestimmten Schwelle hin leeren, so dass TLB-Ungültigkeitserklärungen zu diesem Kern keinen weiteren Effekt haben. Wenn ein Kern eine TLB-Shootdown-Anfrage empfängt, während er in einem Kleinleistungszustand unter der Schwelle ist, kann die Leistungs-Managementeinheit eine Beendigung der TLB-Shootdown-Anfrage im Auftrag des empfangenden Kerns bestätigen, da der empfangende Kern in dem Kleinleistungszustand zuvor seine gesamte TLB losgelassen hat. Durch Zulassen, dass die Leistungs-Managementeinheit eine Beendigung der TLB-Shootdown-Anfrage bestätigt, wird der sendende Kern eine schnellere Antwort auf die Anfrage empfangen als dann, wenn der sendende Kern warten müsste, bis der empfangende Kern zu einem Zustand höherer Leistung zurückkehrte. Weiterhin kann eine Verarbeitung durch den empfangenden Kern nicht durch die TLB-Shootdown-Anfrage unterbrochen werden. Bei einigen Beispielen können andere Komponenten innerhalb des Systems 100, wie beispielsweise eine hochentwickelte programmierbare Unterbrechungssteuerung (APIC) (nicht gezeigt) verwendet werden, um im Auftrag jedes Kerns zu kommunizieren. Beispielsweise kann die APIC eine Beendigung eines TLB-Shootdown bestätigen. Allgemein können andere immer mit Energie versorgte Hardware-Mittel erweitert oder geschaffen werden, um Bestätigungen im Auftrag der Kerne durchzuführen. Beispielsweise wird eine VCPU, die gegenwärtig nich in Betrieb ist, keine zu ihr gehörenden TLB-Einträge haben, so dass ein immer mit Energie versorgte Proxy-Bestätigung die Beendigung der TLB-Shootdown-Anfrage ohne Eingabe von der VCPU zulassen kann.
-
Der sendende Kern kann die Anzahl von von den emfangenden Kernen empfangenen Bestätigungen verfolgen. Diesbezüglich kann der sendende Kern die Anzahl von bei der Benachrichtigungsadresse empfangenen Bestätigungen verfolgen, bis alle der empfangenden Kerne, für die er erwartet, dass sie die TLB-Shootdown-Anfrage bestätigen, dies tun. Beispielsweise kann, basierend auf den in der TLB-Shootdown-Anfrage enthaltenen APICIDs, der sendende Kern wissen, wie viele Bestätigungen erwartet werden. Als solches kann der sendende Kern die Benachrichtigungsadresse überwachen, wie beispielsweise eine spezifische virtuelle oder physikalische Adresse eines Bitvektors, bis diese Anzahl von Bestätigungen empfangen ist. Bei einigen Beispielen kann der sendende Kern einen Betrieb fortsetzen, sobald er die TLB-Shootdown-Anfrage sendet. Um den Zustand der TLB-Shootdown-Anfrage zu überwachen, kann Software, wie beispielsweise das Host-Betriebssystem 231, sicherstellen, dass alle Bestätigungen empfangen worden sind.
-
Wo mehrere Prozessoren innerhalb eines einzigen Systems gefunden werden, kann ein Sockelmanager jedem jeweiligen Prozessor zugeordnet sein. Jeder jeweilige Sockelmanager kann dann die Bestätigungen von allen Kernen innerhalb seines Prozessors überwachen. Der Sockelmanager kann dann die Bestätigungen, die empfangen sind, zu der Benachrichtigungsadresse zurück berichten. Bei einigen Ausführungsformen können die Sockelmanager zu mehr als einem einzigen Prozessor zugeordnet sein. Diesbezüglich können die Sockelmanager zu einem Unterbereich eines Sockels, zu einer Leiterplatte, zu einem Gehäuse, etc. zugeordnet sein.
-
Ein TLB-Shootdown kann durch Schreiben zu einer Cache-Zeile angestosen bzw. getriggert werden. Diesbezüglich kann jede VCPU eine Cache-Zeile in einem gemeinsam genutzten Zustand halten, der pro VM, VCPU Paar eindeutig ist. Um einen TLB-Shootdown szu initiieren kann die VCPU, die den TLB-Shootdown initiiert, zu dieser Cache-Zeile schreiben, was darin resultiert, dass die Cache-Zeile von ihrem jeweilige Cache gelöst wird und einen Hardware- oder Microcode-Mechanismus triggert, der anzeigt, dass der Kern den TLB-Shootdown-Prozess initiieren sollte.
-
Weiterhin können TLB-Shootdowns zu nur spezifischen Kernen gezielt werden. Diesbezüglich kann Software ein Abbilden von allen VCPUs/VMs zu Kernen unterhalten. Basierend auf diesem Abbilden kann der TLB-Shootdown zu nur denjenigen Kernen gezielt werden, die den Prozess verarbeiten, der den TLB-Shootdown triggerte.