DE102016124749B4 - Tlb shootdowns für niedrigen overhead - Google Patents

Tlb shootdowns für niedrigen overhead Download PDF

Info

Publication number
DE102016124749B4
DE102016124749B4 DE102016124749.9A DE102016124749A DE102016124749B4 DE 102016124749 B4 DE102016124749 B4 DE 102016124749B4 DE 102016124749 A DE102016124749 A DE 102016124749A DE 102016124749 B4 DE102016124749 B4 DE 102016124749B4
Authority
DE
Germany
Prior art keywords
tlb
tlb shootdown
core
request
processor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102016124749.9A
Other languages
English (en)
Other versions
DE102016124749A1 (de
Inventor
Eric Northup
Benjamin Charles Serebrin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of DE102016124749A1 publication Critical patent/DE102016124749A1/de
Application granted granted Critical
Publication of DE102016124749B4 publication Critical patent/DE102016124749B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • G06F12/1027Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45583Memory management, e.g. access or allocation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15Use in a specific computing environment
    • G06F2212/152Virtualized environment, e.g. logically partitioned system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68Details of translation look-aside buffer [TLB]
    • G06F2212/682Multiprocessor TLB consistency
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68Details of translation look-aside buffer [TLB]
    • G06F2212/683Invalidation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

Verfahren zum Dirigieren und Verfolgen von Übersetzungspuffer- bzw. Translation Lookaside Buffer- (TLB-)Shootdowns innerhalb von Hardware, umfassend:Detektieren, durch einen oder mehrere Prozessoren (103), wobei jeder Prozessor einen oder mehrere Prozessorkerne (105-111) umfasst, dass ein auf einem ersten Verarbeitungskern ausführender Prozess veranlasst, dass für eine oder mehrere Seiten eines virtuellen Speichers eine Zugehörigkeit mit einer oder mehreren zuvor zugehörigen Adressen eines physikalischen Speichers gelöst werden;Erzeugen, durch den ersten Verarbeitungskern, einer TLB-Shootdown-Anfrage;Senden, durch den ersten Verarbeitungskern, der TLB-Shootdown-Anfrage zu anderen des einen oder der mehreren Verarbeitungskerne, wobei der TLB-Shootdown folgendes umfasst:eine Shootdown-Adresse, die die Seite oder Seiten des virtuellen Speichers, die von der Zugehörigkeit gelöst ist oder sind, anzeigt, um aus den jeweiligen TLBs der anderen Verarbeitungskerne geleert zu werden,eine Benachrichtigungsadresse, die anzeigt, wo die anderen Verarbeitungskerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, undIdentifikationsinformation; undBestimmen, durch ein Hardware-Mittel, ob ein zweiter Kern, der die TLB-Shootdown-Anfrage empfing, in einem Tiefleistungszustand ist, undin dem Fall, in welchem der zweite Kern in einem Tiefleistungszustand ist, Bestätigen der TLB-Shootdown-Anfrage durch das Hardware-Mittel.

Description

  • 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.

Claims (20)

  1. Verfahren zum Dirigieren und Verfolgen von Übersetzungspuffer- bzw. Translation Lookaside Buffer- (TLB-)Shootdowns innerhalb von Hardware, umfassend: Detektieren, durch einen oder mehrere Prozessoren (103), wobei jeder Prozessor einen oder mehrere Prozessorkerne (105-111) umfasst, dass ein auf einem ersten Verarbeitungskern ausführender Prozess veranlasst, dass für eine oder mehrere Seiten eines virtuellen Speichers eine Zugehörigkeit mit einer oder mehreren zuvor zugehörigen Adressen eines physikalischen Speichers gelöst werden; Erzeugen, durch den ersten Verarbeitungskern, einer TLB-Shootdown-Anfrage; Senden, durch den ersten Verarbeitungskern, der TLB-Shootdown-Anfrage zu anderen des einen oder der mehreren Verarbeitungskerne, wobei der TLB-Shootdown folgendes umfasst: eine Shootdown-Adresse, die die Seite oder Seiten des virtuellen Speichers, die von der Zugehörigkeit gelöst ist oder sind, anzeigt, um aus den jeweiligen TLBs der anderen Verarbeitungskerne geleert zu werden, eine Benachrichtigungsadresse, die anzeigt, wo die anderen Verarbeitungskerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, und Identifikationsinformation; und Bestimmen, durch ein Hardware-Mittel, ob ein zweiter Kern, der die TLB-Shootdown-Anfrage empfing, in einem Tiefleistungszustand ist, und in dem Fall, in welchem der zweite Kern in einem Tiefleistungszustand ist, Bestätigen der TLB-Shootdown-Anfrage durch das Hardware-Mittel.
  2. Verfahren nach Anspruch 1, das weiterhin ein Empfangen von Bestätigungen von den anderen Verarbeitungskernen auf ihre Beendigung der TLB-Shootdown-Anfrage hin umfasst, wobei die Bestätigungen bei der Benachrichtigungsadresse empfangen werden.
  3. Verfahren nach Anspruch 1 oder 2, wobei der eine oder die mehreren Prozessoren (103) eine oder mehrere virtuelle Maschinen ausführen, wobei die virtuellen Maschinen einen oder mehrere virtuelle Computerprozessoren (VCPUs) enthalten, und der Prozess eine erster Prozess sein kann, der den einen oder die mehreren VCPUs ausführt.
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Hardware-Mittel eine Leistungs-Managementeinheit (161) ist.
  5. Verfahren nach einem der Ansprüche 1 bis 3, wobei das Hardware-Mittel eine hochentwickelte programmierbare Unterbrechungssteuerung (APIC) ist.
  6. Verfahren nach Anspruch 3, wobei die Identifikationsinformation einen Identifizierer für Komponenten umfasst, wobei die Komponenten eines oder mehreres von einer VM, einer VCPU innerhalb einer VM, einem Prozessorkern und/oder einen innerhalb einer VCPU oder eines Prozessorkerns ausgeführten Prozess umfasst.
  7. Verfahren nach Anspruch 6, das weiterhin folgendes umfasst: Verfolgen der Anzahl von Bestätigungen, die von den Komponenten empfangen sind, die durch die Identifikationsinformation identifiziert sind, bis alle der identifizierten Komponenten den TLB-Shootdown bestätigen; und Beenden, durch den ersten Prozessorkern, der TLB-Shootdown-Anfrage auf ein Empfangen von Bestätigungen von allen der Komponenten, die durch die Identifikationsinformation identifiziert sind.
  8. System zum Dirigieren und Verfolgen von Übersetzungspuffer- bzw. Translation Lookaside Buffer- (TLB-)Shootdowns innerhalb von Hardware, wobei das System folgendes umfasst: einen oder mehrere Prozessoren (103), wobei jeder Prozessor einen oder mehrere Prozessorkerne (105-111) umfasst, wobei der eine oder die mehreren Prozessoren (103) konfiguriert sind, um: zu bestimmen, dass ein auf einem ersten Verarbeitungskern ausführender Prozess veranlasst, dass für eine oder mehrere Seiten eines virtuellen Speichers eine Zugehörigkeit mit einer oder mehreren zuvor zugehörigen Adressen eines physikalischen Speichers gelöst wird; eine TLB-Shootdown-Anfrage zu erzeugen; und die TLB-Shootdown-Anfrage zu anderen des einen oder der mehreren Verarbeitungskerne zu senden, wobei das TLB-Shootdown folgendes umfasst: eine Shootdown-Adresse, die die Seite oder Seiten des virtuellen Speichers, die von der Zugehörigkeit gelöst ist oder sind, anzeigt, um aus den jeweiligen TLBs der anderen Verarbeitungskerne geleert zu werden, eine Benachrichtigungsadresse, die anzeigt, wo die anderen Verarbeitungskerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, und Identifikationsinformation; und ein Hardware-Mittel, wobei das Hardware-Mittel konfiguriert ist, um zu bestimmen, ob ein zweiter Kern, der die TLB-Shootdown-Anfrage empfing, in einem Tiefleistungszustand ist, und in einem Fall, in welchem der zweite Kern in einem Tiefleistungszustand ist, die TLB-Shootdown-Anfrage durch das Hardware-Mittel zu bestätigen.
  9. System nach Anspruch 8, wobei der eine oder die mehreren Prozessoren (103) konfiguriert sind, um auf ihre Beendigung der TLB-Shootdown-Anfrage hin Bestätigungen von den anderen Verarbeitungskernen zu empfangen, wobei die Bestätigungen bei der Benachrichtigungsadresse empfangen werden.
  10. System nach Anspruch 8 oder 9, wobei der eine oder die mehreren Prozessoren (103) konfiguriert sind, um eine oder mehrere virtuelle Maschinen auszuführen, wobei die virtuellen Maschinen einen oder mehrere virtuelle Computerprozessoren (VCPUs) enthalten und der Prozess ein erster Prozess ist, der in dem einen oder den mehreren VCPUs ausführt.
  11. System nach einem der Ansprüche 8 bis 10, wobei das Hardware-Mittel eine Leistungs-Managementeinheit (161) ist.
  12. System nach einem der Ansprüche 8 bis 10, wobei das Hardware-Mittel eine hochentwickelte programmierbare Unterbrechungssteuerung (APIC) ist.
  13. System nach Anspruch 10, wobei die Identifikationsinformation einen Identifizierer für Komponenten umfasst, wobei die Komponenten eines oder mehreres von einer VM, einer VCPU innerhalb einer VM, einem Prozessorkern und/oder einem innerhalb einer VCPU oder eines Prozessorkerns ausgeführten Prozess umfasst.
  14. System nach Anspruch 13, wobei der eine oder die mehreren Prozessoren (103) konfiguriert sind, um die Anzahl von Bestätigungen, die von den Komponenten empfangen sind, die durch die Identifikationsinformation identifiziert sind, zu verfolgen, bis alle der identifizierten Komponenten den TLB-Shootdown bestätigen; und die TLB-Shootdown-Anfrage auf ein Empfangen von Bestätigungen von allen der Komponenten, die durch die Identifikationsinformation identifiziert sind, zu beenden.
  15. Nichtflüchtiges computerlesbares Medium, auf welchem Anweisungen gespeichert sind, wobei die Anweisungen, wenn sie durch einen oder mehrere Prozessoren (103) ausgeführt werden, wobei jeder Prozessor einen oder mehrere Prozessorkerne (105-111) umfasst, veranlassen, dass der eine oder die mehreren Prozessoren (103) ein Verfahren durchführt oder durchführen, das Übersetzungspuffer- bzw. Translation Lookaside Buffer- (TLB)Shootdowns innerhalb von Hardware dirigiert und verfolgt, wobei das Verfahren folgendes umfasst: Bestimmen, dass ein auf einem ersten Verarbeitungskern ausführender Prozess veranlasst, dass für eine oder mehrere Seiten eines virtuellen Speichers eine Zugehörigkeit mit einer oder mehreren zuvor zugehörigen Adressen eines physikalischen Speichers gelöst werden; Erzeugen einer TLB-Shootdown-Anfrage; und Senden der TLB-Shootdown-Anfrage zu anderen des einen oder der mehreren Verarbeitungskerne, wobei der TLB-Shootdown folgendes umfasst: eine Shootdown-Adresse, die die Seite oder Seiten des virtuellen Speichers, die von der Zugehörigkeit gelöst ist oder sind, anzeigt, um aus den jeweiligen TLBs der anderen Verarbeitungskerne geleert zu werden, eine Benachrichtigungsadresse, die anzeigt, wo die anderen Verarbeitungskerne eine Beendigung der TLB-Shootdown-Anfrage bestätigen können, und Identifikationsinformation; und Empfangen einer Bestätigung der TLB-Shootdown-Anfrage von einem Hardware-Mittel in dem Fall, in welchem ein zweiter Kern in einem Tiefleistungszustand ist.
  16. Nichtflüchtiges computerlesbares Medium nach Anspruch 15, wobei das Verfahren weiterhin ein Empfangen von Bestätzigungen von den anderen Verarbeitungskernen auf ihre Beendigung der TLB-Shootdown-Anfrage hin umfasst, wobei die Bestätigungen bei der Benachrichtigungsadresse empfangen werden.
  17. Nichtflüchtiges computerlesbares Medium nach Anspruch 15 oder 16, wobei das Hardware-Mittel eine Leistungs-Managementeinheit (161) ist.
  18. Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 15 bis 16, wobei das Hardware-Mittel eine hochentwickelten programmierbaren Unterbrechungssteuerung (APIC).
  19. Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 15 bis 18, wobei das Verfahren weiterhin ein Ausführen von einer oder mehreren virtuellen Maschinen umfasst, wobei die virtuellen Maschinen einen oder mehrere virtuelle Computerprozessoren (VCPUs) enthalten und der Prozess ein in dem einen oder den mehreren VCPUs ausführender erster Prozess ist.
  20. Nichtflüchtiges computerlesbares Medium nach Anspruch 19, wobei das Verfahren weiterhin ein Verfolgen der Anzahl von Bestätigungen, die von den Komponenten empfangen sind, die durch die Identifikationsinformation identifiziert sind, bis alle der identifizierten Komponenten den TLB-Shootdown bestätigen umfasst; und ein Beenden der TLB-Shootdown-Anfrage auf ein Empfangen von Bestätigungen von allen der Komponenten, die durch die Identifikationsinformation identifiziert sind.
DE102016124749.9A 2016-06-08 2016-12-19 Tlb shootdowns für niedrigen overhead Active DE102016124749B4 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662347495P 2016-06-08 2016-06-08
US62/347,495 2016-06-08
US201615293627A 2016-10-14 2016-10-14
US15/293,627 2016-10-14

Publications (2)

Publication Number Publication Date
DE102016124749A1 DE102016124749A1 (de) 2017-12-14
DE102016124749B4 true DE102016124749B4 (de) 2023-08-10

Family

ID=57569990

Family Applications (2)

Application Number Title Priority Date Filing Date
DE202016008132.3U Active DE202016008132U1 (de) 2016-06-08 2016-12-19 System für TLB-Shootdowns für niedrigen Overhead
DE102016124749.9A Active DE102016124749B4 (de) 2016-06-08 2016-12-19 Tlb shootdowns für niedrigen overhead

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE202016008132.3U Active DE202016008132U1 (de) 2016-06-08 2016-12-19 System für TLB-Shootdowns für niedrigen Overhead

Country Status (6)

Country Link
EP (2) EP3255550B1 (de)
JP (2) JP6382924B2 (de)
CN (2) CN112286839B (de)
DE (2) DE202016008132U1 (de)
DK (2) DK3502906T3 (de)
GB (1) GB2551226A (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108710584B (zh) * 2018-05-22 2021-08-31 郑州云海信息技术有限公司 一种提高tlb刷新效率的方法
CN114595164B (zh) * 2022-05-09 2022-08-16 支付宝(杭州)信息技术有限公司 在虚拟化平台中管理tlb高速缓存的方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026359A1 (en) 2004-07-30 2006-02-02 Ross Jonathan K Multiprocessor system having plural memory locations for respectively storing TLB-shootdown data for plural processor nodes
US20160041922A1 (en) 2014-07-21 2016-02-11 Via Alliance Semiconductor Co., Ltd. Efficient address translation caching in a processor that supports a large number of different address spaces

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63286944A (ja) * 1987-05-20 1988-11-24 Hitachi Ltd アドレス変換バツフア無効化方式
JPH01109452A (ja) * 1987-10-22 1989-04-26 Fujitsu Ltd 変換索引バッファ情報の消去制御方式
JP2806778B2 (ja) * 1994-01-28 1998-09-30 甲府日本電気株式会社 変換索引バッファクリア命令処理方式
JP4361909B2 (ja) * 1995-03-20 2009-11-11 富士通株式会社 キャッシュコヒーレンス装置
US5906001A (en) * 1996-12-19 1999-05-18 Intel Corporation Method and apparatus for performing TLB shutdown operations in a multiprocessor system without invoking interrup handler routines
US20040117590A1 (en) * 2002-12-12 2004-06-17 International Business Machines Corp. Aliasing support for a data processing system having no system memory
US7073043B2 (en) * 2003-04-28 2006-07-04 International Business Machines Corporation Multiprocessor system supporting multiple outstanding TLBI operations per partition
US7188229B2 (en) * 2004-01-17 2007-03-06 Sun Microsystems, Inc. Method and apparatus for memory management in a multi-processor computer system
US7454590B2 (en) * 2005-09-09 2008-11-18 Sun Microsystems, Inc. Multithreaded processor having a source processor core to subsequently delay continued processing of demap operation until responses are received from each of remaining processor cores
JP4908017B2 (ja) * 2006-02-28 2012-04-04 富士通株式会社 Dmaデータ転送装置及びdmaデータ転送方法
US20120203831A1 (en) * 2011-02-03 2012-08-09 Kent Schoen Sponsored Stories Unit Creation from Organic Activity Stream
CN101398768B (zh) * 2008-10-28 2011-06-15 北京航空航天大学 一种分布式虚拟机监视器系统的构建方法
CN102262557B (zh) * 2010-05-25 2015-01-21 运软网络科技(上海)有限公司 通过总线架构构建虚拟机监控器的方法及性能服务框架
US9916257B2 (en) * 2011-07-26 2018-03-13 Intel Corporation Method and apparatus for TLB shoot-down in a heterogeneous computing system supporting shared virtual memory
CN104204990B (zh) * 2012-03-30 2018-04-10 英特尔公司 在使用共享虚拟存储器的处理器中加速操作的装置和方法
US9081707B2 (en) * 2012-12-29 2015-07-14 Intel Corporation Apparatus and method for tracking TLB flushes on a per thread basis
US9411745B2 (en) * 2013-10-04 2016-08-09 Qualcomm Incorporated Multi-core heterogeneous system translation lookaside buffer coherency
US9619387B2 (en) * 2014-02-21 2017-04-11 Arm Limited Invalidating stored address translations
JP6663108B2 (ja) * 2016-02-29 2020-03-11 富士通株式会社 物理演算処理装置、情報処理装置及び情報処理装置の制御方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060026359A1 (en) 2004-07-30 2006-02-02 Ross Jonathan K Multiprocessor system having plural memory locations for respectively storing TLB-shootdown data for plural processor nodes
US20160041922A1 (en) 2014-07-21 2016-02-11 Via Alliance Semiconductor Co., Ltd. Efficient address translation caching in a processor that supports a large number of different address spaces

Also Published As

Publication number Publication date
GB201621246D0 (en) 2017-01-25
EP3255550B1 (de) 2019-04-03
DE202016008132U1 (de) 2017-04-24
GB2551226A (en) 2017-12-13
EP3255550A1 (de) 2017-12-13
JP6382924B2 (ja) 2018-08-29
EP3502906A1 (de) 2019-06-26
JP6716645B2 (ja) 2020-07-01
JP2018181378A (ja) 2018-11-15
EP3502906B1 (de) 2021-06-16
CN112286839A (zh) 2021-01-29
CN107480075A (zh) 2017-12-15
CN107480075B (zh) 2020-10-27
DE102016124749A1 (de) 2017-12-14
JP2017220211A (ja) 2017-12-14
CN112286839B (zh) 2024-05-10
DK3502906T3 (da) 2021-08-30
DK3255550T3 (da) 2019-07-15

Similar Documents

Publication Publication Date Title
DE602004011018T2 (de) Ungültigkeitserklärung eines speichers und löschen von puffereinträgen
DE112018002951T5 (de) Verwenden eines spurformatcodes in einem cache-steuerblock für eine spur in einem cache, um lese- und schreibanforderungen in bezug auf die spur im cache zu verarbeiten
DE112005002405B4 (de) Fehlerverarbeitung für Direktspeicherzugriffs-Adreßübersetzung
DE112005002304B4 (de) Adreßumsetzung für Eingabe/Ausgabe- Vorrichtungen mittels hierarchischer Umsetzungstabellen
DE112011102183B4 (de) Beschleuniger für die Migration virtueller Maschinen
DE112012002241T5 (de) Migration eines transparenten Dateisystems zu einem neuen physischen Speicherort
DE102015002582A1 (de) Architekturübergreifendes Kompatibilitätsmodul, um zuzulassen, dass ein Codemodul einer Architektur ein Bibliotheksmodul einer anderen Architektur verwendet
DE112011100323T5 (de) Architekturübergreifende Migration virtueller Maschinen
DE112013004400B4 (de) Herstellen einer Zeitpunktkopie-Beziehung zwischen logischen Quellenadressen und logischen Zieladressen
DE112010005821T5 (de) Kontextwechsel
DE112012005209T5 (de) Brückenfunktion zwischen Virtual Machine Monitor und Bare-Metal-Bootvorgang
DE112011102822T5 (de) Leistungsoptimierte Interrupt-Abgabe
DE112018005404T5 (de) Vereinfachen des zugriffs auf lokalitätsdomäneninformationen eines speichers
DE112016001730T5 (de) Virtuelle Maschinensysteme
DE112015000203T5 (de) "Compare and Delay"-Befehle
DE112017005063T5 (de) Verwalten eines Speichers mit niedrigstem Kohärenzpunkt (LPC) mithilfe eines Dienstschichtadapters
DE112018006068T5 (de) Dynamische adressübersetzung für eine virtuelle maschine
DE112018005768T5 (de) Copy-source-to-target-verwaltung in einem datenspeichersystem
US10977191B2 (en) TLB shootdowns for low overhead
DE102016124749B4 (de) Tlb shootdowns für niedrigen overhead
DE102021101709A1 (de) Virtuelle serielle schnittstellen für virtuelle maschinen
DE112020005106T5 (de) Verfahren und systeme zum umsetzen von virtuellen adressen in einem auf virtuellem speicher beruhenden system
DE112011100854T5 (de) Schnelle Datenfernübertragung und Fernberechnung zwischen Prozessoren
DE102013022166B4 (de) Seitenzustandsverzeichnis zur verwaltung eines vereinheitlichten virtuellen speichers
DE102019111780A1 (de) Atomare befehle für copy-xor von daten

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R138 Derivation of utility model

Ref document number: 202016008132

Country of ref document: DE

R081 Change of applicant/patentee

Owner name: GOOGLE LLC (N.D.GES.D. STAATES DELAWARE), MOUN, US

Free format text: FORMER OWNER: GOOGLE INC., MOUNTAIN VIEW, CALIF., US

R082 Change of representative

Representative=s name: BETTEN & RESCH PATENT- UND RECHTSANWAELTE PART, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division