DE69838969T2

DE69838969T2 - Multiprozessor-Rechnersystem und Verfahren zu seinem Betrieb

Info

Publication number: DE69838969T2
Application number: DE1998638969
Authority: DE
Inventors: Karen Pembroke Noel; Thomas Hollis Benson; Gregory H. Hollis Jordan; James R. Nashua Kauffman; Andrew H. Hollis Mason; Paul K. Groton Harter; Richard A. Merrimack Bishop; Frederick G. Amherst Kleinsorge; Stephen Acton Shirron; Stephen Redmond Zalewski
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1997-11-04
Filing date: 1998-11-04
Publication date: 2008-12-24
Anticipated expiration: 2018-11-05
Also published as: DE69838969D1

Description

Diese Erfindung bezieht sich auf Multiprozessor-Computerarchitekturen, bei denen Prozessoren und andere Computerhardware-Ressourcen zu Partitionen gruppiert sind, die jeweils über eine Betriebssystem-Instanz verfügen.
Die effiziente Ausführung zahlreicher Applikationen bei vorliegenden Computerumgebungen hängt von schnellen, leistungsfähigen und flexiblen Berechnungssystemen ab. Die Konfiguration und die Gestaltung derartiger Systeme wird äußerst aufwendig, wenn derartige Systeme in einer kommerziellen "Unternehmens"-Umgebung verwendet werden sollen, in der es zahlreiche getrennte Abteilungen, zahlreiche unterschiedliche Problemarten und sich fortwährend ändernde Berechungsanforderungen geben kann. Benutzer in derartigen Umgebungen möchten im allgemeinen in der Lage sein, schnell und einfach die Kapazität des Systems, dessen Geschwindigkeit und dessen Konfiguration zu ändern. Sie möchten zudem die Systemarbeitsleistung erweitern und Konfigurationen ändern, um eine bessere Nutzung von Ressourcen zu erreichen, ohne die Ausführung von Applikationsprogrammen im System zu stoppen. Darüber hinaus möchten sie möglicherweise in der Lage sein, das System zu konfigurieren, um die Verfügbarkeit von Ressourcen zu maximieren, so dass jede Applikation eine optimale Berechungskonfiguration hat.
Normalerweise wurde sich der Berechungsgeschwindigkeit mit Hilfe einer "Shared-Nothing"-Berechnungsarchitektur zugewandt, bei der Daten, eine Unternehmenslogik und grafische Benutzerschnittstellen ausgeprägte Stufen sind und über spezifische Berechnungsressourcen verfügen, die jeder Stufe zugewiesen sind. Anfänglich wurde eine einzige Zentralverarbeitungseinheit verwendet und die Leistung sowie die Geschwindigkeit eines derartigen Berechungssystems durch Erhöhen einer Taktrate der einzigen Zentralverarbeitungseinheit verbessert. In jüngerer Zeit wurden Berechungssysteme entwickelt, die zahlreiche Prozessoren verwenden, die als Gemeinschaft arbeiten, anstelle einen großen Prozessor alleine arbeiten zu lassen. Auf diese Weise kann eine komplexe Applikation auf mehrere Prozessoren verteilt werden, anstelle darauf zu warten, dass diese von einem einzigen Prozessor ausgeführt wird. Derartige Systeme bestehen normalerweise aus mehreren Zentralverarbeitungseinheiten (CPUs), die von einem einzigen Betriebssystem gesteuert werden. Bei einer Variante eines Mehrprozessorsystems, das "Symmetrisches Multiprocessing" oder SMP genannt wird, sind die Applikationen gleichmäßig auf sämtliche Prozessoren verteilt. Die Prozessoren nutzen zudem gemeinsam einen Speicher. Bei einer weiteren Variante, die "Asymmetrisches Multiprocessing" oder AMP genannt wird, verhält sich ein Prozessor wie ein "Master", und die anderen Prozessoren verhalten sich als "Slaves". Somit müssen sämtliche Vorgänge einschließlich des Betriebssystems den Master durchlaufen, bevor sie zu den Slave-Prozessoren weitergereicht werden. Diese Multiprozessorarchitekturen haben den Vorteil, dass das Leistungsverhalten erhöht werden kann, indem zusätzliche Prozessoren hinzugefügt werden, haben jedoch den Nachteil, dass die Software, die auf derartigen Systemen läuft, sorgfältig geschrieben sein muss, um die zahlreichen Prozessoren zu nutzen, und es Schwierigkeiten bereitet, die Software anzupassen, wenn die Zahl der Prozessoren zunimmt. Momentan kommerzielle Arbeitslasten lassen sich nicht gut auf über 8 bis 24 CPUs als einziges SMP-System erweitern, wobei die exakte Zahl von der Plattform, dem Betriebssystem und dem Applikationsgemisch abhängt.
Für ein erweitertes Leitungsverhalten bestand eine weitere typische Antwort darin, Computerressourcen (Maschinen) einer Applikation zuzuweisen, um die Maschinenressourcen optimal auf die Applikation abzustimmen. Dieser Ansatz wurde jedoch von der Mehrzahl der Benutzer nicht angenommen, da die meisten Orte über zahlreiche Applikationen und getrennte Datenbanken verfügen, die von unterschiedlichen Anbietern entwickelt werden. Somit ist es schwierig und teuer, Ressourcen unter sämtlichen Applikationen insbesondere in Umgebungen zuzuweisen, in denen sich das Applikationsgemisch fortwährend ändert. Zudem ist es bei zugewiesenen Ressourcen insbesondere dann im wesentlichen unmöglich, Ressourcen schnell und einfach von einem Computersystem auf ein weiteres Computersystem zu migrieren, wenn unterschiedliche Anbieter beteiligt sind. Selbst wenn eine derartige Migration ausgeführt werden kann, beinhaltet sie normalerweise das Einschreiten eines Systemadministrators und verfangt es, dass wenigstens einige der Computersysteme heruntergefahren und neugestartet werden.
Alternativ dazu kann ein Berechnungssystem mit Hardware partitioniert werden, um einen Teilsatz der Ressourcen in einem Computer einer speziellen Applikation zugänglich zu machen. Dieser Ansatz vermeidet die dauerhafte Zuweisung von Ressourcen, da die Partitionen geändert werden können, löst jedoch nicht das Problem, das die Verbesserungen des Leistungsverhaltens mit Hilfe eines Belastungsausgleiches von Ressourcen unter Partitionen und die Verfügbarkeit von Ressourcen betrifft.
Den Angelegenheiten der Verfügbarkeit und der Instandhaltbarkeit wurde durch ein "Shared-Everything"-Modell Rechnung getragen, bei dem ein großer, zentraler, leistungsstarker Server, der den Großteil der Ressourcen enthält, mit vielen kleinen, unkomplizierten Client-Netzwerkcomputern vernetzt ist und diesen Dienste bereitstellt. Alternativ dazu werden "Cluster" verwendet, bei denen jedes System oder jeder "Knoten" seinen eigenen Speicher hat und mit seinem eigenen Betriebssystem gesteuert wird. Die Systeme interagieren durch gemeinsame Nutzung von Platten und das Weiterleiten von Nachrichten untereinander über einen bestimmten Typ eines Kommunikationsnetzwerkes. Ein Cluster-System hat den Vorteil, dass zusätzliche Systeme auf einfache Weise einem Cluster hinzugefügt werden können. Netzwerke und Cluster leiden jedoch unter einem Mangel an gemeinsam genutztem Speicher und unter begrenzter Zwischenverbindungsbandbreite, die Einschränkungen für das Leistungsverhalten darstellt.
Bei zahlreichen Berechungsumgebungen in Unternehmen ist es klar, dass die beiden getrennten Berechnungsmodelle gleichzeitig untergebracht werden müssen und jedes Modell optimiert werden muss. Zudem ist es äußerst wünschenswert, dass die Möglichkeit besteht, dass Computerkonfigurationen "fliegend" ohne Neustart eines der Systeme abgeändert werden können. Es wurden zahlreiche Ansätze des Standes der Technik angewendet, um diese Anpassung zu versuchen. Beispielsweise verwendet ein Aufbau mit dem Namen "Virtuelle Maschine" oder VM, der von der International Business Machines Corporation, Armonk, New York, entwickelt und vermarktet wird, eine einzige physikalische Maschine mit einem oder mehreren Prozessoren in Kombination mit Software, die mehrere virtuelle Maschinen simuliert. Jede dieser virtuellen Maschinen hat im Prinzip Zugriff auf sämtliche physikalischen Ressourcen des zugrundeliegenden realen Computers. Die Zuweisung der Ressourcen auf jede virtuelle Maschine wird von einem Programm gesteuert, das "Hypervisor" genannt wird. Es gibt lediglich einen Hypervisor im System, wobei dieser für sämtliche physikalischen Ressourcen verantwortlich ist. Demzufolge beschäftigt sich der Hypervisor und nicht die anderen Betriebssysteme mit der Zuordnung physikalischer Hardware. Der Hypervisor fängt Anfragen nach Ressourcen von den anderen Betriebssystemen ab und beschäftigt sich mit den Anfragen auf global korrekte Art und Weise.
Die VM-Architektur unterstützt das Konzept einer "logischen Partition" oder einer LPAR. Jede LPAR enthält einige der verfügbaren physikalischen CPUs und Ressourcen, die der Partition logisch zugewiesen sind. Diese Ressourcen können mehr als einer Partition zugeordnet sein. LPARs werden von einem Administrator statisch eingerichtet, können jedoch auf Belastungsänderungen dynamisch und ohne Neustarten auf unterschiedliche Art und Weise reagieren. Wenn beispielsweise zwei logische Partitionen, die jeweils zehn CPUs enthalten, in einem physikalischen System gemeinsam genutzt werden, das zehn physikalische CPUs enthält, und wenn die logischen zehn CPU-Partitionen komplementäre Spitzenbelastungen aufweisen, kann jede Partition das gesamte System aus zehn physikalischen CPUs bei Verschiebung der Arbeitslast ohne Neustart oder Eingreifen durch die Bedienperson übernehmen.
Darüber hinaus können die CPUs, die jeder Partition logisch zugewiesen sind, über herkömmliche Betriebssystem-Bedienpersonbefehle ohne Neustarten dynamisch "ein"- und "aus"-geschaltet werden. Die einzige Einschränkung besteht darin, dass die Zahl von CPUs, die bei der Systeminitialisierung aktiv sind, die Maximalzahl von CPUs ist, die auf einer beliebigen Partition "ein"-geschaltet werden können.
In Fällen, bei denen schließlich der angesammelte Arbeitslastbedarf sämtlicher Partitionen größer ist, als er vom physikalischen System bereitgestellt werden kann, können LPAR"-Belastungen" verwendet werden, um den Anteil der gesamten CPU-Ressourcen zu definieren, der jeder Partition gegeben wird. Diese Belastungen können durch Systemadministratoren fliegend ohne Unterbrechung geändert werden.
Ein weiteres System des Standes der Technik wird als "Parallel Sysplex" bezeichnet und wird ebenfalls von der International Business Machines Corporation vertrieben und entwickelt. Diese Architektur besteht aus einem Satz von Computer, die über eine Hardwareeinheit geclustert sind, die als "Kopplungseinrichtung" bezeichnet wird und an jeder CPU angebracht ist. Die Kopplungseinrichtungen an jedem Knoten sind über eine Faseroptikverbindung verbunden, und jeder Knoten arbeitet als herkömmliche SMP-Maschine mit einem Maximum von 10 CPUs. Bestimmte CPU-Anweisungen rufen direkt eine Kopplungseinrichtung auf. Ein Knoten registriert beispielsweise eine Datenstruktur mit der Kopplungseinrichtung, worauf die Kopplungseinrichtung dafür sorgt, dass die Datenstrukturen innerhalb des lokalen Speichers jedes Knotens kohärent bleiben.
Der Enterprise 10000 Unix-Server, der von Sun Microsystems, Mountain View, Kalifornien entwickelt und vertrieben wird, verwendet eine Partitionierungsanordnung mit dem Namen "Dynamic System Domains", um die Ressourcen eines einzigen physikalischen Servers in mehrere Partitionen oder Domänen zu unterteilen, die jeweils als eigenständiger Server arbeiten. Jede der Partitionen verfügt über CPUs, einen Speicher und I/O-Hardware. Eine dynamische Neukonfiguration gestattet es einen Systemadministrator Domänen "fliegend" ohne Neustart zu erzeugen, in der Größe anzupassen und zu löschen. Jede Domäne bleibt von einer beliebigen weiteren Domäne im System isoliert, wodurch sie vollständig von einem Softwarefehler oder CPU-, Speicher oder I/O-Fehler isoliert bleibt, der von einer beliebigen anderen Domäne erzeugt wird. Es gibt keine gemeinsame Nutzung von Ressourcen zwischen beliebigen dieser Domänen.
Das Hive-Project, das an der Stanford University durchgeführt wird, verwendet eine Architektur, die aus einem Satz von Zellen aufgebaut ist. Startet das System, wird jede Zeile einem Bereich von Knoten zugewiesen, die jeweils über Speicher- und I/O-Vorrichtungen verfügen, die die Zelle während der Ausführung besitzt. Jede Zelle verwaltet die Prozessoren, den Speicher und I/O-Vorrichtungen an diesen Knoten, als ob sie ein unabhängiges Betriebssystem wäre. Die Zellen arbeiten zusammen, um den Eindruck eines einzigen Betriebssystems für Vorgänge auf Benutzerebene zu erwecken.
Hive-Zellen sind nicht für die Entscheidung verantwortlich, wie ihre Ressourcen zwischen lokalen und entfernten Anfragen zu unterteilen sind. Jede Zelle ist lediglich für den Beibehalt ihrer internen Ressourcen und für die Optimierung des Leistungsverhaltens innerhalb der Ressourcen verantwortlich, die ihr zugeordnet wurden. Die globale Ressourcenzuordnung wird von einem Vorgang auf Benutzerebene ausgeführt, der "Anwachsen" genannt wird. Das Hive-System versucht, eine Datenverfälschung mit Hilfe bestimmter Fehlereindämmungsgrenzen zwischen den Zellen zu verhindern. Um die enge gemeinsam Nutzung anzuwenden, die von einem Multiprozessorsystem erwartet wird, wird trotz der Fehlereindämmungsgrenzen zwischen den Zellen, die gemeinsame Nutzung von Ressourcen durch das Zusammenwirken der unterschiedlichen Zell-Kernels angewendet, wobei jedoch die Richtlinie außerhalb der Kernels beim Anwachsen angewendet wird. Sowohl der Speicher als auch die Prozessoren können gemeinsam genutzt werden.
Ein System mit dem Namen "Cellular IRIX", das von der Silicon Graphics Inc., Mountain View, Kalifornien, entwickelt und vertrieben wird, unterstützt modulares Berechnen durch Erweiterung herkömmlicher symmetrischer Multiprozessorsysteme. Die Architektur des Cellular IRIX verteilt globalen Kernel-Text und Daten auf optimierte Stücke in SMP-Größe oder "Zellen". Zellen repräsentieren eine Steuerdomäne, die aus einem oder mehreren Maschinenmodulen besteht, wobei jedes Modul aus Prozessoren, Speicher und I/O besteht. Applikationen, die auf diesen Zellen laufen, greifen umfangreich auf einen vollen Satz lokaler Betriebssystemdienste zurück, die lokale Kopien von Betriebssystemtext und Kernel-Datenstrukturen enthalten, wobei jedoch lediglich eine Instanz des Betriebssystems im gesamten System existiert. Eine Koordination zwischen den Zellen gestattet es Applikationsbildern, direkt und transparent Verarbeitungs-, Speicher- und I/O-Ressourcen von anderen Zellen zu nutzen, ohne den zusätzlichen Aufwand von Datenkopien oder zusätzlichen Kontext-Switches hervorzurufen.
Eine weitere bestehende Architektur mit dem Namen NUMA-Q, die von Sequent Computer Systems, Ind., Beaverton, Oregon, entwickelt und vertrieben wird, verwendet "Quads" oder eine Gruppe von vier Prozessoren je Speicherabschnitt als Basisaufbaublock für NUMA-Q-SMP-Knoten. Das Hinzufügen von I/O zu jedem Quad verbessert weiterhin das Leistungsverhalten. Somit verteilt die NUMA-Q-Architektur nicht nur physikalischen Speicher, sondern bringt eine vorbestimmte Zahl von Prozessoren und PCI-Steckplätzen in die Nähe jedes Prozessors. Der Speicher in jedem Quad ist kein lokaler Speicher im herkömmlichen Sinne. Anstelle dessen ist er ein Teil des physikalischen Speicheradressraumes und hat einen speziellen Adressbereich. Das Adresskennfeld ist gleichmäßig über den Speicher verteilt, wobei jeder Quad einen zusammenhängenden Teil eines Adressraumes hat. Es läuft lediglich eine Kopie des Betriebssystems, wobei sich dieses, wie bei einem beliebigen SMP-System, im Speicher befindet und Prozesse ohne Unterscheidung und gleichzeitig auf einem oder mehreren Prozessoren ausführt.
Wenngleich zahlreiche Versuche unternommen wurden, ein flexibles Computersystem bereitzustellen, haben bestehende Systeme demzufolge bedeutende Unzulänglichkeiten. Daher wäre es wünschenswert, über einen neuen Aufbau eines Computersystems zu verfügen, der eine verbesserte Flexibilität, eine verbesserte Verfügbarkeit von Ressourcen, verbesserte Ressourcen-Migrationsmöglichkeiten und eine verbesserte Anpassbarkeit bereitstellt.
US-A-5574914 beschreibt eine Vorrichtung und ein Verfahren zum Verwalten einer Anzahl von Datenverarbeitungsressourcen, um eine oder mehrere unabhängige und separate Datenverarbeitungspartitionen zu verwalten. Es ist eine dynamische Neukonfigurationskapazität vorgesehen, die es gestattet, dass Ressourcen einer Anzahl von anderweitig autonomen Systemen zugeordnet werden, die eine zentralisierte Steuereinheit verwenden. Es ist ein Zwischenverbindungsmechanismus beschrieben, um Systemressourcen zu verbinden, und es ist ein Softwaremechanismus beschrieben, der die zuweisbaren Systemressourcen einer Vielzahl von Partitionen zuweist. Diese Beschreibung sagt jedoch nichts über ein Betriebssystem der Vorrichtung aus.
Bob Beck: "AAMP: A Multiprocessor Approach for Operating System and Application Migration" Operating Systems Review (SIGOPS), US, ACM Headquarters, New York, vol. 24, no. 2, 1. April 1990, Seite 41–55 beschreibt ein Verfahren für den Betrieb von mehreren Multiprozessor-Betriebssystemen auf mehreren durch eine Anweisung eingestellten Prozessoren. Das Verfahren, das in dieser Druckschrift beschrieben ist, unterstützt den Betrieb unterschiedlicher Betriebssysteme auf Prozessoren in einem Multiprozessorsystem und die Anpassung mehrerer durch eine Anweisung eingestellter Prozessoren. Diese Beschreibung sagt jedoch nichts über einen Neustart eines Computersystems aus.
Gemäß der vorliegenden Erfindung wird ein Computersystem mit einer Vielzahl von zuweisbaren Systemressourcen angegeben, enthaltend Prozessoren, einen Speicher und I/O-Schaltkreise, wobei das Computersystem enthält:
einen Verbindungsmechanismus, der die Prozessoren, den Speicher und die I/O-Schaltkreise derart verbindet, dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einige der I/O-Schaltkreise hat;
einen Softwaremechanismus, der die zuweisbaren Systemressourcen einer Vielzahl von Partitionen zuweist, wobei jede Partition wenigstens einen Prozessor, einen Teil des Speichers und einen Teil der I/O-Schaltkreise enthält;
eine Instanz eines Betriebssystems, das auf jeder Partition läuft; wobei
wenigstens eine Gruppe von Partitionen eine Gemeinschaft bildet, die Speicher gemeinsam nutzt; und
eine Prozessor-Migrationsvorrichtung, die einen ersten Prozessor aus einer ersten Partition einer zweiten Partition ohne Neustart des gesamten Systems neu zuweist, wobei die Migrationsvorrichtung einen Verarbeitungskontext des Prozessors im Bezug auf die erste Partition vor der Neuzuweisung speichert und nach der Neuzuweisung des ersten Prozessors der erste Prozessor einen beliebigen Verarbeitungskontext lädt, den er während einer vorherigen Ausführung mit der zweiten Partition gespeichert haben kann.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Betreiben eines Computersystems angegeben, das über eine Vielzahl von zu weisbaren Systemressourcen verfügt, enthaltend Prozessoren, einen Speicher und I/O-Schaltkreise, wobei das Verfahren folgende Schritte enthält:

(a) elektrisches Verbinden der Prozessoren, des Speichers und der I/O-Schaltkreise, so dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einen Teil der I/O-Schaltkreise hat;
(b) Zuweisen der zuweisbaren Systemressourcen zu einer Vielzahl von Partitionen, wobei jede Partition wenigstens einen Prozessor, einen Teil des Speichers und einen Teil der I/O-Schaltkreise enthält;
(c) Ausführen einer Betriebssystem-Instanz auf jeder Partition;
(d) Ausbilden einer Gemeinschaft von Partitionen durch gemeinsames Nutzen von Speicher aus einer Gruppe von Partitionen und

Die obigen und weiteren Vorteile der Erfindung werden unter Bezugnahme auf die folgende Beschreibung in Verbindung mit den beiliegenden Zeichnungen besser verständlich.
1 ist ein schematisches Blockschaltbild einer Hardwareplattform, das zahlreiche Systemaufbaublöcke darstellt.
2 ist eine schematische Darstellung eines APMP-Computersystems, das gemäß den Prinzipien der vorliegenden Erfindung aufgebaut ist und zahlreiche Partitionen zeigt.
3 ist eine schematische Darstellung eines Konfigurationsbaumes, der Hardwareressourcen-Konfigurationen und Software-Konfigurationen sowie deren Bestandteile mit Kind- und Geschwister-Verweisen darstellt.
4 ist eine schematische Darstellung des Konfigurationsbaumes aus 3, die neugeordnet ist, um die Zuweisung von Hardware- und Softwareinstanzen durch Zugehörigkeits-Verweise darzustellen.
5 ist ein Flussdiagramm, das Schritte in einer beispielhaften Routine zum Erzeugen eines APMP-Computersystems gemäß den Prinzipien der vorliegenden Erfindung zeigt.
6 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zum Erzeugen von Einträgen in einer APMP-System-Verwaltungsdatenbank zeigt, die Informationen bereithält, die das APMP-System und dessen Konfiguration betreffen.
7A und 7B bilden zusammen ein Flussdiagramm, das im Detail die Schritte in einer beispielhaften Routine zum Erzeugen eines APMP-Computersystems gemäß den Prinzipien der vorliegenden Erfindung zeigt.
8A und 8B bilden zusammen ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen eine Betriebssystem-Instanz folgt, um einem APMP-Computersystem beizutreten, das bereits erzeugt ist.
9 ist ein Flussdiagramm, das allgemein die Schritte zum Migrieren einer Ressource von einer Partition zu einer weiteren darstellt.
10A–10E sind schematische Blockdarstellungen, die grafisch die Schritte zum Migrieren einer Ressource von einer Partition zu einer weiteren zeigen.
11 ist ein schematisches Blockschaltbild, das einen Überblick über das System der Erfindung zeigt.
12 ist ein schematisches Blockschaltbild, das das Berechungssystem der Erfindung zeigt, das als Shared-Nothing-Berechnungssystem arbeitet.
13 ist ein schematisches Blockschaltbild, das das Berechungssystem der Erfindung zeigt, das als Shared-Partial-Berechnungssystem arbeitet.
14 ist ein schematisches Blockschaltbild, das das Berechungssystem der Erfindung zeigt, das als Shared-Everything-Berechnungssystem arbeitet.
15 ist ein schematisches Blockschaltbild, das die Migration von CPUs im Berechungssystem der Erfindung darstellt.
16 ist eine schematische Ansicht von Sätzen, die von Instanzen verwendet werden, die auf zahlreichen entsprechenden Partitionen des Computersystems der vorliegenden Erfindung laufen, sowie der Kategorisierung von CPUs des Systems im Bezug auf diese Instanzen.
17 ist eine schematische Ansicht einer Partition und eines Satzes von Speicherorten, die verwendet werden um zu kennzeichnen, welche CPUs des Systems sich in unterschiedlichen Sätzen der Instanz befinden, die auf der Partition läuft.
18 ist eine schematische Ansicht ähnlich 17, die jedoch einen zusätzlichen Satz im Bezug auf eine alternative Ausführungsform der Erfindung zeigt.
19 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, gefolgt von einer Betriebssystem-Instanz, wie sie privaten Speicher aus einem System entfernt.
20 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen eine Betriebssystem-Instanz folgt, wenn sie gemeinsam genutzten Speicher aus einem System entfernt.
21 ist ein Speicherkennfeld einer PFN-Datenbank gemäß der Erfindung.
22 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen eine CPU folgt, die von einer Partition zu einer weiteren Partition bei einer "PAL"-Typ-Migration migriert.
23 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen eine Software in einer Partition folgt, zu der eine CPU migriert.
24 ist eine schematische Ansicht einer ersten Partition und einer Sicherungs-Partition, zu der Ressourcen der ersten Partition bei auftreten eines Fehlers in der ersten Partition migriert werden.
25 ist eine schematische Ansicht einer Anordnung von Ziel-Instanzen-IDs, die von einer lokalen Instanz verwendet werden, um die Bestimmungspartitionen von Ressourcen zu bestimmen, die aus einer Partition als Teil eines gesteuerten Abschaltens migriert werden, wenn ein Fehler in der lokalen Instanz aufgetreten ist.
26A–26B bilden zusammen ein Flussdiagramm, das den allgemeinen Ablauf darstellt, denen eine Ressourcen-Neuverteilung folgt, nachdem ein Fehler in einer Instanz einer ersten Partition auftritt.
27 ist ein Flussdiagramm, das den Ablauf zeigt, dem eine CPU folgt, die von einer Instanz migriert, in der ein Fehler aufgetreten ist.
28 ist ein Flussdiagramm, das die Schritte zeigt, denen während einer anfänglichen Zuweisung der Dauerzugehörigkeit einer CPU der vorliegenden Erfindung gefolgt wird.
29 ist ein Flussdiagramm, das die Schritte zeigt, denen während einer Änderung der Dauerzugehörigkeit einer CPU der vorliegenden Erfindung gefolgt wird.
30A–30C bilden zusammen ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen vom System gefolgt wird, wenn eine CPU unter einer "HALT"-Typ-Migration migriert.
31 ist ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen vom System gefolgt wird, wenn eine CPU in einem angehaltenen Zustand migriert wird.
32A–32B bilden zusammen ein Flussdiagramm, das die Schritte in einer beispielhaften Routine zeigt, denen vom System gefolgt wird, wenn eine CPU durch Aufhebung der Zuweisung und anschließendes Neuzuweisen migriert wird.
33A und 33B bilden zusammen ein Flussdiagramm, das die Schritte in einer Routine zeigt, denen durch zwei Betriebssystem-Instanzen gefolgt wird, um von einer Instanz zur anderen Instanz mit Hilfe der Einzelbit-Meldung zu kommunizieren.
34A und 34B bilden zusammen ein Flussdiagramm, das die Schritte in einer Routine zeigt, denen von zwei Betriebssystem-Instanzen gefolgt wird, um von einer Instanz zur anderen Instanz mit Hilfe der paketierten Datenübertragung zu kommunizieren.
A. GESAMTSYSTEM
Eine Computerplattform, die gemäß den Prinzipien der vorliegenden Erfindung aufgebaut ist, ist ein Multiprozessorsystem, das partitioniert werden kann, um die gleichzeitige Ausführung von mehreren Instanzen der Betriebssystemsoftware zu gestatten. Das System verlangt keinen Hardwaresupport für die Partitionierung seines Speichers, seiner CPUs und der I/O-Teilsysteme, wobei jedoch eine bestimmte Hardware verwendet werden kann, um eine zusätzliche Hardwareunterstützung zum Isolieren von Fehlern und Minimieren der Kosten der Softwareentwicklung bereitzustellen. Die folgende Beschreibung erläutert die Schnittstellen und die Datenstrukturen, die erforderlich sind, um die Softwarearchitektur der vorliegenden Erfindung zu unterstützen. Die beschriebenen Schnittstelen und Daten strukturen implizieren nicht, dass ein spezielles Betriebssystem verwendet werden muss, oder dass lediglich ein einziger Typ eines Betriebssystems gleichzeitig ausgeführt wird. Jedes beliebige Betriebssystem, das die Software-Erfordernisse implementiert, die im folgenden beschrieben werden, kann an der Ausführung des Systems der Erfindung teilnehmen.
Systemaufbaublöcke
Die Softwarearchitektur der Erfindung arbeitet auf einer Hardwareplattform, die mehrere CPUs, einen Speicher und I/O-Hardware enthält. Vorzugsweise wird eine modulare Architektur verwendet, wie sie in 1 gezeigt ist, wenngleich der Fachmann verstehen wird, dass ebenfalls andere Architekturen verwendet werden können, wobei diese Architekturen nicht modular sein müssen. 1 zeigt ein Berechnungssystem, das aus vier Basis-Systemaufbaublöcken (SBBs) 100–106 aufgebaut ist. Bei der beispielhaften Ausführungsform ist jeder Aufbaublock, wie etwa Block 100, identisch und enthält zahlreiche CPUs 108–114, mehrere Speichersteckplätze (die gemeinsam als Speicher 120 gekennzeichnet sind), einen I/O-Prozessor 118, und einen Anschluss 116, der einen Schalter (nicht gezeigt) enthält, der das System mit einem weiteren derartigen System verbinden kann. Bei anderen Ausführungsformen müssen die Aufbaublöcke jedoch nicht identisch sein. Große Multiprozessorsysteme können aufgebaut werden, indem die gewünschte Anzahl von Systemaufbaublöcken mit Hilfe ihrer Anschlüsse verbunden werden. Eine Umschalttechnik wird anstelle einer Bustechnik verwendet, um die Aufbaublockbestandteile zu verbinden, um sowohl eine verbesserte Bandbreite zu erzielen als auch nicht einheitliche Speicherarchitekturen (NUMA) zuzulassen.
Gemäß den Prinzipien der Erfindung sind die Hardware-Umschalter derart angeordnet, dass jede CPU sämtlichen verfügbaren Speicher und I/O-Anschlüsse unabhängig von der Zahl der Aufbaublöcke adressieren kann, die so konfiguriert sind, wie es mit der Linie 122 dargestellt ist. Darüber hinaus können sämtliche CPUs mit einer beliebigen oder sämtlichen anderen CPUs in sämtlichen SBBs mit herkömmlichen Mechanismen, wie etwa Zwischenprozessor-Interrupts kommunizieren. Demzufolge können die CPUs und andere Hardware-Ressourcen einzig durch Software zugeordnet werden. Eine derartige Plattformarchitektur ist an sich skalierbar, so dass ein großer Umfang von Verarbeitungsleistung, Speicher und I/O in einem einzigen Computer verfügbar sind.
Ein AMPM-Computersystem 200, das in Übereinstimmung mit den Prinzipien der vorliegenden Erfindung vom Standpunkt der Software aufgebaut ist, ist in 2 gezeigt. In diesem System wurden die Hardware-Bestandteile zugeordnet, um die gleichzeitige Ausführung von mehreren Betriebssysteminstanzen 208, 210, 212 zu gestatten. Bei einer bevorzugten Ausführungsform wird diese Zuordnung von einem Softwareprogramm ausgeführt, das "Konsolen"-Programm genannt wird und, wie es später im Detail beschrieben werden wird, beim Starten in den Speicher geladen wird. Konsolen-Programme sind schematisch in 2 als Programme 213, 215 und 217 dargestellt. Das Konsolen-Programm kann eine Abänderung eines bestehenden administrativen Programms oder ein separates Programm sein, das mit einem Betriebssystem zusammenarbeitet, um den Betrieb der bevorzugten Ausführungsform zu steuern. Das Konsolen-Programm virtualisiert nicht die Systemressourcen, d. h. es erzeugt keine Software-Schichten zwischen den laufenden Betriebssystemen 208, 210 und 212 und der physikalischen Hardware, wie etwa dem Speicher und I/O-Einheiten (nicht gezeigt in 2). Zudem wird der Status der laufenden Betriebssysteme 208, 210 und 212 nicht gewechselt, um Zugriff auf die Hardware zu erlangen. Anstelle dessen unterteilt das System der Erfindung die Hardware logisch in Partitionen. Es liegt in der Verantwortlichkeit der Betriebssystem-Instanz 208, 210 und 212, die Ressourcen in der geeigneten Weise zu verwenden und eine Koordination der Ressourcenzuordnung und der gemeinsamen Nutzung bereitzustellen. Die Hardware-Plattform kann optional eine Hardware-Unterstützung für die Unterteilung von Ressourcen bereitstellen und kann Fehlerbarrieren bereitstellen, um die Fähigkeit eines Betriebssystems zu minimieren, Speicher zu beschädigen oder Vorrichtungen zu beeinflussen, die von einer weiteren Betriebssystemkopie gesteuert werden.
Die Ausführungsumgebung für eine einzige Kopie eines Betriebssystems, wie etwa die Kopie 208, wird "Partition" 202 genannt, und das ausführende Betriebssystem 208 auf der Partition 202 wird "Instanz" 208 genannt. Jede Betriebssystem-Instanz ist in der Lage, unabhängig von allen anderen Betriebssystem- Instanzen im Computersystem zu starten und zu laufen und kann kooperativ bei der gemeinsamen Nutzung von Ressourcen zwischen Betriebssystem-Instanzen teilnehmen, wie sie im folgenden beschrieben sind.
Um eine Betriebssystem-Instanz auszuführen, muss eine Partition einen Hardware-Neustartparameterblock (HWRPB), eine Kopie eines Konsolen-Programms, eine gewisse Speichermenge, eine oder mehrere CPUs und wenigstens einen I/O-Bus beinhalten, der über einen zugewiesenen physikalischen Anschluss für die Konsole verfügen muss. Der HWRPB ist ein Konfigurationsblock, der zwischen dem Konsolen-Programm und dem Betriebssystem weitergereicht wird. Jedes der Konsolen-Programme 213, 215 und 217 ist mit einem Konsolenanschluss verbunden, die als Anschlüsse 214, 216 bzw. 218 dargestellt sind. Die Konsolenanschlüsse, wie etwa die Anschlüsse 214, 216 und 218 kommen im allgemeinen in Gestalt eines Seriellleitungsanschlusses oder angefügter Grafik-, Tastatur- und Maus-Optionen. Für die Zwecke des Computersystems der Erfindung ist die Fähigkeit der Unterstützung eines zugewiesenen Grafikanschlusses und zugeordneter Eingabevorrichtungen nicht erforderlich, wenngleich es ein spezielles Betriebssystem erfordern könnte. Die Grundannahme besteht darin, dass ein serieller Anschluss für jede Partition ausreichend ist. Wenngleich ein separates Endgerät oder eine unabhängige Grafikkonsole verwendet werden könnten, um Informationen anzuzeigen, die von jeder Konsole erzeugt werden, können vorzugsweise die seriellen Leitungen 220, 222 und 224 allesamt mit einem einzigen Multiplexer 226 verbunden sein, der an einer Workstation, einem PC oder einem LAT 228 angebracht ist, um Konsoleninformationen anzuzeigen.
Es ist wichtig, darauf hinzuweisen, dass Partitionen nicht gleichbedeutend mit den Systemaufbaublöcken sind. Beispielsweise kann die Partition 202 die Hardware in den Aufbaublöcken 100 und 106 in 1 enthalten, während die Partitionen 204 und 206 die Hardware in den Aufbaublöcken 102 bzw. 104 enthalten können. Partitionen können zudem einen Teil der Hardware in einem Aufbaublock enthalten.
Partitionen können "initialisiert" oder "uninitialisiert" sein. Eine initialisierte Partition verfügt über ausreichend Ressourcen, um eine Betriebssystem-Instanz aus zuführen, hat ein geladenes Konsolen-Programm-Image und eine CPU, die verfügbar und ausführend ist. Eine initialisierte Partition kann von einem Konsolen-Programm gesteuert werden oder kann eine Betriebssystem-Instanz ausführen. In einem initialisierten Zustand hat eine Partition die vollständige Zugehörigkeit und Steuerung der Hardwarekomponenten, die ihr zugewiesen sind, wobei nur die Partition an sich, ihre Komponenten freigeben kann.
Gemäß den Prinzipien der vorliegenden Erfindung können Ressourcen von einer initialisierten Partition zu einer weiteren Partition neu zugewiesen werden. Die Neuzuweisung von Ressourcen kann lediglich von der initialisierten Partition ausgeführt werden, der die Ressource momentan zugewiesen ist. Befindet sich eine Partition in einem uninitialisierten Zustand, können andere Partitionen ihre Hardware-Komponenten neu zuweisen und diese löschen.
Eine uninitialisierte Partition ist eine Partition, die keine primäre CPU hat, die entweder unter Steuerung eines Konsolen-Programms oder eines Betriebssystems ausführend ist. Eine Partition kann beispielsweise infolge eines Mangels ausreichender Ressourcen beim Starten einer primären CPU unpartitioniert sein, oder wenn ein Systemadministrator das Computersystem neu konfiguriert. In einem uninitialisierten Zustand kann eine Partition ihre Hardwarekomponenten neu zuweisen und von einer weiteren Partition gelöscht werden. Nicht zugewiesene Ressourcen können von einer beliebigen Partition zugewiesen werden. Partitionen können zu "Gemeinschaften" organisiert werden, die die Basis zum Gruppieren separater Ausführungskontexte bereitstellen, um eine kooperative gemeinsame Nutzung von Ressourcen zu erlauben. Partitionen in derselben Gemeinschaft können Ressourcen gemeinsam nutzen. Partitionen, die sich nicht in derselben Gemeinschaft bilden, können Ressourcen nicht gemeinsam nutzen. Ressourcen können lediglich manuell zwischen Partitionen, die sich nicht in derselben Gemeinschaft befinden, vom Systemadministrator bewegt werden, indem die Zuweisung der Ressource aufgehoben wird (und die Verwendung gestoppt wird) und die Ressource manuell neu konfiguriert wird. Gemeinschaften können verwendet werden, um unabhängige Betriebssystemdomänen zu erzeugen oder um Benutzerrichtlinien für die Hardwarenutzung zu implementieren. In 2 wurden die Partitionen 202 und 204 zur Gemeinschaft 230 organisiert. Die Partition 206 kann sich in ihrer eigenen Gemeinschaft 205 befinden. Die Gemeinschaften können aufgebaut werden, indem der Konfigurationsbaum verwendet wird, der unten beschrieben ist, und können von der Hardware durchgesetzt werden.
Das Konsolen-Programm
Wenn ein Computersystem, das gemäß den Prinzipien der vorliegenden Erfindung aufgebaut ist, auf einer Plattform in Kraft gesetzt wird, müssen mehrere HWRPBs erzeugt, mehrere Kopien des Konsolen-Programms geladen und Systemressourcen derart zugewiesen werden, dass jeder HWRPB speziellen Komponenten des Systems zugeordnet wird. Zu diesem Zweck erzeugt das erste ablaufende Konsolen-Programm eine Konfigurationsbaumstruktur im Speicher, die die gesamte Hardware im System repräsentiert. Der Baum wird zudem die Softwarepartitionsinformationen sowie die Zuweisungen der Hardware zu den Partitionen enthalten und ist im folgenden detailliert beschrieben. Wenn das APMP-System eingeschaltet wird, wird insbesondere eine CPU als primäre CPU auf herkömmliche Weise durch Hardware gewählt, die für die Plattform spezifisch ist, auf der das System läuft. Die primäre CPU lädt anschließend eine Kopie eines Konsolen-Programms in den Speicher. Diese Konsole wird "Master-Konsolen"-Programm genannt. Die primäre CPU arbeitet zu Beginn unter Steuerung das Master-Konsolen-Programms, um einen Test und eine Prüfung auszuführen, vorausgesetzt, dass es ein einziges System gibt, das der gesamten Maschine zugehörig ist. Anschließend wird ein Satz von Umgebungsvariablen geladen, die die Systempartitionen definieren. Schließlich erzeugt und initialisiert die Master-Konsole die Partitionen auf der Basis der Umgebungsvariablen. Bei diesem letztgenannten Vorgang arbeitet die Master-Konsole derart, dass sie den Konfigurationsbaum erzeugt, dass sie zusätzliche HWRPB-Datenblöcke erzeugt, dass sie die zusätzlichen Kopien des Konsolen-Programms lädt und dass sie die CPUs auf den alternativen HWRPBs startet. Jede Partition verfügt daraufhin über eine Betriebssystem-Instanz, die auf ihr läuft, wobei diese Instanz mit einer Kopie des Konsolen-Programms zusammenarbeitet, die ebenfalls auf dieser Partition läuft. Bei einem nicht konfigurierten APMP-System erzeugt das Master-Konsolen-Programm zu Beginn eine einzige Partition, die die primäre CPU, eine minimale Größe des Speichers und eine Administrator-Konsole des physikalischen Systems enthält, die auf plattformspezifische Art und Weise gewählt ist. Konsolen-Programm-Befehle gestatten es anschließend dem Systemadministrator, zusätzliche Partitionen zu erzeugen und I/O-Busse, Speicher und CPUs für jede Partition zu konfigurieren.
Nachdem Zuordnungen von Ressourcen zu Partitionen vom Konsolen-Programm vorgenommen wurden, werden die Zuordnungen im nicht flüchtigen RAM gespeichert, um eine automatische Konfiguration des Systems während anschließender Startvorgänge zu gestatten. Während anschließender Startvorgänge muss das Master-Konsolen-Programm die momentane Konfiguration mit der gespeicherten Konfiguration validieren, um das Entfernen und das hinzufügen neuer Komponenten zu handhaben. Neu hinzugefügte Komponenten werden in einen nicht zugewiesenen Zustand versetzt, bis sie vom Systemadministrator zugewiesen werden. Wenn das Entfernen eine Hardwarekomponente dazu führt, dass eine Partition mit unzureichenden Ressourcen ein Betriebssystem ablaufen lässt, werden Ressourcen weiterhin der Partition zugeordnet, wobei diese jedoch nicht in der Lage sein werden, eine Betriebssystem-Instanz ablaufen zu lassen, solange nicht zusätzliche Ressourcen dieser zugeordnet sind. Wie es zuvor erwähnt wurde, kommuniziert das Konsolen-Programm mit einer Betriebssystem-Instanz mit Hilfe eines HWRPB, der während des Starts des Betriebssystems an das Betriebssystem weitergeleitet wird. Die fundamentalen Anforderungen für ein Konsolen-Programm bestehen darin, dass es in der Lage sein sollte, mehrere Kopien von HWRPBs und sich selbst zu erzeugen. Jede HWRPB-Kopie, die vom Konsolen-Programm erzeugt wird, wird in der Lage sein, eine unabhängige Betriebssystem-Instanz in einen privaten Abschnitt des Speichers zu starten, wobei jede Betriebssystem-Instanz, die auf diese Weise gestartet wird, von einem einzigartigen Wert identifiziert werden kann, der in den HWRPB plaziert wird. Der Wert kennzeichnet die Partition und wird zudem als ID der Betriebssystem-Instanz verwendet.
Darüber hinaus ist das Konsolen-Programm so konfiguriert, dass es einen Mechanismus bereitstellt, um eine CPU aus den verfügbaren CPUs innerhalb einer Partition in Erwiderung einer Anfrage durch ein Betriebssystem zu entfernen, das auf dieser Partition läuft. Jede Betriebssystem-Instanz muss in der Lage sein, sich in der Weise abzuschalten, anzuhalten oder andernfalls abzustürzen, in der die Steuerung an das Konsolen-Programm übergeben wird. Im Gegensatz dazu muss jede Betriebssysteminstanz in der Lage sein, in einen Betriebszustand unabhängig von einer beliebigen anderen Betriebssystem-Instanz neuzustarten.
Jeder HWRPB, der von einem Konsolen-Programm erzeugt wird, enthält eine CPU-schlitzspezifische Datenbank für jede CPU, die sich im System befindet, oder die dem System hinzugefügt werden kann, ohne das gesamte System herunterzufahren. Jede CPU, die physikalisch präsent ist, wird als "präsent" markiert, wobei jedoch lediglich CPUs, die zu Beginn auf einer speziellen Partition ausgeführt werden, als "verfügbar" im HWRPB für die Partition markiert werden. Die Betriebssystem-Instanz, die auf einer Partition läuft, wird in der Lage sein, durch ein vorhandenes (PP)-Bit in Zustandskennzeichenfeldern je CPU des HWRPB zu erkennen, dass eine CPU zu einem späteren Zeitpunkt verfügbar sein kann, und kann Datenstrukturen aufbauen, um dies wiederzuspiegeln. Wenn es eingestellt ist, kennzeichnet das verfügbare (PA)-Bit in den Zustandskennzeichenfeldern je CPU, dass die zugeordnete CPU momentan der Partition zugeordnet ist und aufgefordert werden kann, am SMP-Betrieb teilzunehmen.
Der Konfigurationsbaum
Wie es zuvor erwähnt wurde, erzeugt das Master-Konsolen-Programm einen Konfigurationsbaum, der die Hardware-Konfiguration und die Zuweisung jeder Komponente im System zu jeder Partition repräsentiert. Jedes Konsolen-Programm identifiziert anschließend den Konfigurationsbaum für seine zugeordnete Betriebssystem-Instanz durch Plazieren eines Verweises auf den Baum im HWRPB. Unter Bezugnahme auf 3 repräsentiert der Konfigurationsbaum 300 die Hardware-Komponenten im System, die Plattformbeschränkungen und Minima sowie die Software-Konfiguration. Das Master-Konsolen-Programm baut den Baum mit Hilfe von Informationen, die durch Testen der Hardware festgestellt werden, und aus Informationen auf, die im nicht flüchtigen RAM gespeichert sind, der Konfigurationsinformationen enthält, die während vorheriger Initialisierungen erzeugt werden.
Die Master-Konsole kann eine einzige Kopie des Baumes erzeugen, wobei diese Kopie von sämtlichen Betriebssystem-Instanzen gemeinsam genutzt wird, oder sie kann den Baum für jede Instanz replizieren. Eine einzige Kopie des Baumes hat den Nachteil, dass sie einen einzigen Fehlerpunkt in Systemen mit unabhängigen Speichern erzeugen kann. Plattformen, die mehrere Baumkopien erzeugen, verlangen es jedoch, dass die Konsolen-Programme in der Lage sind, die Änderungen am Baum synchron zu halten.
Der Konfigurationsbaum enthält mehrere Knoten, die Wurzelknoten, Kindknoten und Geschwisterknoten beinhalten. Jeder Knoten besteht aus einem fixierten Header und einer Erweiterung variabler Länge für überlagerte Datenstrukturen. Der Baum beginnt mit einem Baumwurzelknoten 302, der den gesamten Systemkasten repräsentiert, gefolgt von Zweigen, die die Hardware-Konfiguration (Hardware-Wurzelknoten 304), die Software-Konfiguration (Software-Wurzelknoten 306) und die minimalen Partitionsanforderungen (Masken-Wurzelknoten 308) beschreiben. In 3 repräsentieren die Pfeile Kind- und Geschwister-Beziehungen. Die Kinder eines Knotens repräsentieren Komponententeile der Hardware- oder Software-Konfiguration. Geschwister repräsentieren Peers einer Komponente, auf die sich ggf. nicht bezogen wird, mit der Ausnahme, dass sie dieselben Eltern hat. Knoten im Baum 300 enthalten Informationen über die Software-Gemeinschaften und Betriebssystem-Instanzen, Grenzen des Leistungsverhaltens sowie Hot-Swap-Fähigkeiten. Die Knoten stellen zudem die Beziehung von Hardware-zu-Software-Zugehörigkeit oder die gemeinsame Nutzung einer Hardware-Komponente bereit. Die Knoten sind aneinandergrenzend im Speicher gespeichert, wobei der Adressen-Offset vom Baumwurzelknoten 302 des Baumes 300 zu einem spezifischen Knoten ein "Handle" bildet, das von einer beliebigen Betriebssystem-Instanz verwendet werden kann, um unmissverständlich diese Komponente an einer beliebigen Betriebssystem-Instanz zu identifizieren. Darüber hinaus hat jede Komponente im Computersystem der Erfindung eine separate ID. Diese kann beispielsweise ein vorzeichenloser 64-Bit-Wert sein. Die ID muss eine einzigartige Komponente festlegen, wenn sie mit den Typ- und Teiltypwerten der Komponente kombiniert wird. Das heißt, für einen gegebenen Typ der Komponente muss die ID eine spezielle Komponente identifizieren. Die ID kann eine einfache Zahl, wie etwa die CPU-ID, eine bestimmte andere einzigartige Codierung oder eine physikalische Adresse sein. Die Komponenten-ID und das Handle gestatten es einem beliebigen Teilnehmer des Computersystems, ein spezielles Stück von Hardware oder Software zu identifizieren. Das heißt, eine beliebige Partition, die eines der Spezifikationsverfahren verwendet, muss in der Lage sein, dieselbe Spezifikation zu verwenden, und dasselbe Ergebnis ermitteln.
Wie es oben beschrieben wurde, besteht das Computersystem aus einer oder mehreren Gemeinschaften, die ihrerseits aus einer oder mehreren Partitionen bestehen. Durch Aufteilen der Partitionen auf die unabhängigen Gemeinschaften kann das Computersystem der Erfindung in eine Konfiguration versetzt werden, in der die gemeinsame Nutzung von Vorrichtungen und des Speichers begrenzt werden kann. Gemeinschaften und Partitionen werden IDs haben, die dicht gepackt sind. Die Hardware-Plattform wird die maximale Zahl von Partitionen auf der Basis der Hardware bestimmen, die im System vorhanden ist wie auch über eine Plattform-Maximalgrenze verfügen. Die Partitions- und Gemeinschafts-IDs werden diesen Wert während der Laufzeit niemals überschreiten. IDs werden für gelöschte Partitionen und Gemeinschaften erneut verwendet werden. Die maximale Zahl von Gemeinschaften ist dieselbe wie die maximale Zahl von Partitionen. Darüber hinaus wird jede Betriebssystem-Instanz von einem einzigartigen Instanz-Identifikator, wie etwa einer Kombination aus der Partitions-ID plus einer Inkarnationszahl, identifiziert.
Die Gemeinschaften und Partitionen werden durch einen Software-Wurzelknoten 306 repräsentiert, der Gemeinschafts-Knotenkinder (von denen der Gemeinschaftsknoten 310 dargestellt ist) und Partitions-Knotenenkel (von denen zwei Knoten 312 und 314 dargestellt sind) hat. Die Hardware-Komponenten werden von einem Hardware-Wurzelknoten 304 repräsentiert, der Kinder enthält, die eine hierarchische Darstellung der gesamten Hardware repräsentieren, die derzeit im Computersystem vorhanden ist. Die "Zugehörigkeit" einer Hardware-Komponente wird durch ein Handle im zugeordneten Hardware-Knoten repräsentiert, der auf den geeigneten Software-Knoten (310, 312 oder 314) verweist. Diese Handles sind in 4 dargestellt, die im folgenden detaillierter erläutert werden. Komponenten, die einer speziellen Partition zugehörig sind, haben Handles, die auf den Knoten verweisen, der die Partition repräsentiert. Hardware, die von mehreren Partitionen (wie etwa dem Speicher) gemeinsam genutzt wird, verfügt über Handles, die auf die Gemeinschaft verweisen, auf die die gemeinsame Nutzung begrenzt ist. Hardware ohne Zugehörigkeit hat ein Handle von Null (der den Baumwurzelknoten 302 repräsentiert).
Hardwarekomponenten bestimmen Konfigurationsbeschränkungen, wie eine Zugehörigkeit unterteilt sein kann. Ein "Konfigurations"-Handle im Konfigurationsbaumknoten, der jeder Komponente zugeordnet ist, bestimmt, ob die Komponente frei ist, um an beliebiger Stelle im Computersystem zugeordnet zu werden, indem auf den Hardware-Wurzelknoten 304 verwiesen wird. Einige Hardware-Komponenten können jedoch an einen Stammknoten gebunden sein und müssen als Teil dieses Knoten konfiguriert sein. Beispiele hierfür können CPUs sein, die keine Einschränkungen haben, wo sie ausgeführt werden, die jedoch Bestandteil eines Systemaufbaublocks (SBB) sind, wie etwa die SBBs 322 oder 324. Wenngleich die CPU ein Kind des SBB ist, wird in diesem Fall ihr Konfigurations-Handle auf den Hardware-Wurzelknoten 304 verweisen. Ein I/O-Bus ist jedoch ggf. nicht in der Lage, einer anderen Partition zugehörig zu sein, als der Partition, die dessen I/O-Prozessor besitzt. In diesem Fall hat der Konfigurationsbaumknoten, der den I/O-Bus repräsentiert, ein Konfigurations-Handle, das auf den I/O-Prozessor verweist. Da die Regeln, die die Hardwarekonfiguration bestimmen, plattformspezifisch sind, werden diese Informationen den Betriebssysteminstanzen durch das Konfigurations-Handle zugeführt. Jede Hardware-Komponente hat zudem ein "Affinitäts"-Handle. Das Affinitäts-Handle ist identisch mit dem Konfigurations-Handle, mit der Ausnahme, dass es eine Konfiguration repräsentiert, die das beste Leistungsverhalten der Komponente erzielt. Eine CPU oder ein Speicher können beispielsweise ein Konfigurations-Handle haben, das es gestattet, an beliebiger Stelle im Computersystem konfiguriert zu werden (es verweist auf den Hardware-Wurzelknoten 304), wobei für ein optimales Leistungsverhalten die CPU oder der Speicher derart konfiguriert sein sollten, dass sie den Systemaufbaublock verwenden, dessen Bestandteil sie sind. Das Ergebnis besteht darin, dass der Konfigurationsverweis auf den Hardware-Wurzelknoten 304 verweist und der Affinitätsverweis auf einen SBB-Knoten, wie etwa den Knoten 322 oder 324 verweist. Die Affinität einer beliebigen Komponente ist plattformspezi fisch und durch die Firmware bestimmt. Die Firmware kann diese Informationen verwenden, wenn sie abgerufen werden, um "optimale" automatische Konfigurationen zu bilden.
Jeder Knoten enthält zudem zahlreiche Kennzeichen, die den Typ und Zustand des Knotens kennzeichnen. Diese Kennzeichen beinhalten ein node_hotswap-Kennzeichen, das kennzeichnet, dass die dargestellte Komponente eine Komponente ist, die sich für einen "Hot-Swap" eignet und unabhängig von ihren Eltern und Geschwistern heruntergefahren werden kann. Es müssen jedoch sämtliche Kinder dieses Knotens herunterfahren, wenn diese Komponente herunterfährt. Können die Kinder unabhängig von dieser Komponente herunterfahren, muss dieses Bit ebenfalls in ihren entsprechenden Knoten eingestellt sein. Ein weiteres Kennzeichen ist ein node_unavailable-Kennzeichen, das, sofern es eingestellt ist, kennzeichnet, dass die Komponente, die vom Knoten repräsentiert wird, momentan für die Verwendung nicht verfügbar ist. Wird eine Komponente heruntergefahren (oder niemals eingeschaltet), wird sie als nicht verfügbar gekennzeichnet.
Zwei Kennzeichen node_hardware und node_template kennzeichnen den Knotentyp. Weitere Kenzeichen, wie etwa node_initialized und node_cpu_primary können ebenfalls vorgesehen sein um zu kennzeichnen, ob der Knoten eine Partition, die initialisiert wurde, oder eine CPU kennzeichnet, die derzeit eine primäre CPU ist.
Der Konfigurationsbaum 300 kann sich auf die Ebene von Vorrichtungs-Controllern erstrecken, die es dem Betriebssystem gestatten, Bus- und Vorrichtungs-Konfigurationstabellen aufzubauen, ohne die Busse zu überprüfen. Der Baum kann jedoch auch auf einer beliebigen Ebene enden, wenn sämtliche Komponenten unter dieser nicht unabhängig konfiguriert werden können. Die Systemsoftware ist weiterhin erforderlich, um Bus- und Vorrichtungsinformationen zu prüfen, die nicht vom Baum bereitgestellt werden.
Das Konsolen-Programm implementiert und setzt, sofern vorhanden, Konfigurationsbeschränkungen an jeder Komponente des Systems durch. Im allgemeinen sind Komponenten entweder ohne Einschränkungen durchsetzbar (beispielswei se können CPUs keine Einschränkungen haben) oder sind lediglich als Teil einer weiteren Komponente konfigurierbar (ein Vorrichtungsadapter kann beispielsweise lediglich als Teil seines Busses konfigurierbar sein). Eine Partition, die, wie oben erläutert, eine Gruppierung von CPUs, Speicher und I/O-Vorrichtungen zu einer einzigartigen Softwareeinheit ist, hat ebenfalls minimale Anforderungen. Beispielsweise sind die minimalen Hardware-Anforderungen für eine Partition wenigstens eine CPU, ein gewisser privater Speicher (plattformabhängiges Minimum, einschließlich dem Konsolen-Speicher) und ein I/O-Bus, einschließlich einem physikalischen, nicht gemeinsam genutzten Konsolenanschluss.
Die minimalen Komponentenanforderungen für eine Partition werden von den Informationen vorgegeben, die im Masken-Wurzelknoten 308 enthalten sind. Der Masken-Wurzelknoten 308 enthält Knoten 316, 318 und 320, die die Hardware-Komponenten repräsentieren, die bereitgestellt sein müssen, um eine Partition zu erzeugen, die zur Ausführung eines Konsolen-Programms und einer Betriebssystem-Instanz in der Lage ist. Konfigruations-Editoren können diese Informationen als Basis verwenden um zu ermitteln, welche Typen und wie viele Ressourcen verfügbar sein müssen, um eine neue Partition zu bilden.
Während des Aufbaus einer neuen Partition "wandert" der Masken-Teilbaum, und für jeden Knoten im Masken-Teilbaum muss es einen Knoten mit demselben Typ und Teiltyp geben, der der neuen Partition zugehörig ist, so dass sie in der Lage ist, ein Konsolen-Programm zu laden und eine Betriebssystem-Instanz zu starten. Gibt es mehr als einen Knoten desselben Typs und Teiltyps im Maskenbaum, muss es ebenfalls mehrere Knoten in der neuen Partition geben. Das Konsolen-Programm verwendet die Maske um zu validieren, dass eine neue Partition die minimalen Anforderungen erfüllt, bevor versucht wird, ein Konsolen-Programm zu laden und den Betrieb zu initialisieren.
Das folgende ist ein detailliertes Beispiel einer speziellen Anwendung von Konfigurationsbaum-Knoten. Es dient Beschreibungszwecken und ist daher nicht einschränkend. Jeder HWRPB muss auf einen Konfigurationsbaum verweisen, der die momentane Konfiguration und die Zuweisungen von Komponenten auf Partitionen bereitstellt. Es wird ein Konfigurationsverweis (Im CONFIG-Feld) im HWRPB verwendet, um auf den Konfigurationsbaum zu verweisen. Das CONFIG-Feld verweist auf einen 64-Byte-Header, der die Größe des Speichervorrates für den Baum und die Ausgangsprüfsumme des Speichers enthält. Auf den Header folgt unmittelbar der Wurzelknoten des Baumes. Der Header und der Wurzelknoten des Baumes sind seitenartig ausgerichtet.
Die Gesamtgröße in Bytes des Speichers, der für den Konfigurationsbaum zugeordnet ist, befindet sich im ersten Quadword des Headers. Es ist garantiert, dass die Größe in Vielfachen der Hardware-Seitengröße vorliegt. Das zweite Quadword des Headers ist für eine Prüfsumme reserviert. Um den Konfigurationsbaum zu untersuchen, bildet eine Betriebssystem-Instanz den Baum auf seinen lokalen Adressenraum ab. Da eine Betriebssystem-Instanz diesen Speicher mit Lesezugriff, der für alle Applikationen zulässig ist, abbilden kann, muss eine Vorkehrung getroffen werden um zu verhindern, dass eine nicht privilegierte Applikation Zugriff auf Konsolendaten gewinnt, auf die sie keinen Zugriff haben sollte. Der Zugriff kann durch eine geeignete Zuordnung von Speicher beschränkt werden. Beispielsweise kann der Speicher seitenmäßig ausgerichtet sein und in gesamten Seiten zugeordnet sein. Normalerweise bildet eine Betriebssystem-Instanz die erste Seite des Konfigurationsbaumes ab, bezieht die Baumgröße und bildet anschließend den Speicher erneut ab, der für die Verwendung des Konfigurationsbaumes zugeordnet wird. Die Gesamtgröße kann zusätzlichen Speicher beinhalten, der von der Konsole für dynamische Änderungen am Baum verwendet wird.
Vorzugsweise werden Konfigurationsbaum-Knoten mit fixierten Headern ausgebildet und können wahlweise typenspezifische Informationen beinhalten, die dem fixierten Abschnitt folgen. Das Größenfeld enthält die volle Länge des Knotens, wobei die Knoten veranschaulichend in Vielfachen von 64 Bytes angeordnet sind und je nach Bedarf aufgefüllt werden. Die folgende Beschreibung definiert beispielhafte Felder im fixierten Header für einen Knoten:
Bei der obigen Definition sind die Typendefinitionen "uint" vorzeichenlose ganze Zahlen mit den geeigneten Bitlängen. Wie es zuvor erwähnt wurde, werden Knoten von einem Handle lokalisiert und identifiziert (identifiziert durch typedef GCT_HANDLE in der obigen Definition). Ein beispielhaftes Handle ist ein vorzeichenbehafteter 32-Bit Offset von der Basis des Konfigurationsbaumes zum Knoten. Der Wert ist über sämtliche Partitionen im Computersystem einzigartig. Das heißt, ein Handle, das man in einer Partition erhält, muss gültig sein, um einen Knoten, oder als Eingabe für eine Konsolen-Rückfrage, auf allen Partitionen zu finden. Das magische Feld enthält ein vorbestimmtes Bitmuster, das kennzeichnet, das der Knoten tatsächlich ein gültiger Knoten ist.
Der Baumwurzelknoten repräsentiert das gesamte System. Sein Handle ist immer Null. Das heißt, er befindet sich immer an der ersten physikalischen Stelle im Speicher, der für den Konfigurationsbaum zugeordnet ist, der dem Konfigurations-Header folgt. Er hat die folgende Definition:
Die Felder im Wurzelknoten sind wie folgt definiert:
lock
Diese Feld wird als einfache Verriegelung von einer Software, die Änderungen an der Struktur des Baumes verhindern will, und der Softwarekonfiguration verwendet. Wenn dieser Wert –1 ist (alle Bits ein), ist der Baum nicht verriegelt; wenn der Wert >= 0 ist, ist der Baum verriegelt. Dieses Feld wird mit Hilfe atomischer Operationen abgeändert. Der Anrufer der Verriegelungsroutine leitet eine Partitions-ID weiter, die in das Verriegelungsfeld geschrieben ist. Diese kann als Unterstützung bei der Fehlerverfolgung und bei der Wiederherstellung während Abstürzen verwendet werden.
transient_level
Dieses Feld wird zu Beginn einer Baumaktualisierung erhöht.
current_level
Dieses Feld wird bei Vervollständigung einer Baumaktualisierung aktualisiert.
console_req
Dieses Feld legt den erforderlichen Speicher in Bytes für die Konsole im Basisspeichersegment einer Partition fest.
min_alloc
Dieses Feld hält die Minimalgröße eines Speicherfragmentes und die Zuordnungseinheit (Fragmentgrößen müssen ein Vielfaches der Zuordnung sein). Sie muss eine Potenz von 2 sein.
min_align
Dieses Feld hält die Ausrichtungsanforderungen für ein Speicherfragment. Es muss eine Potenz von 2 sein.
base_alloc
Dieses Feld legt den minimalen Speicher in Bytes (einschließlich console_req) fest, der für das Basisspeichersegment für eine Partition gebraucht wird. Dorthin werden die Konsole, die Konsolenstrukturen und das Betriebssystem für eine Partition geladen. Es muss größer oder gleich minAlloc und ein Vielfaches von minAlloc sein.
base_align
Dieses Feld hält das Ausrichtungserfordernis für das Basisspeichersegment einer Partition. Es muss eine Potenz von 2 sein und eine Ausrichtung von wenigstens min_align haben.
max_phys_address
Dieses Feld hält die berechnete größte physikalische Adresse, die im System existieren könnte, einschließlich Speicherteilsystemen, die momentan nicht eingeschaltet sind und verfügbar sind.
mem_size
Dieses Feld hält den Gesamtspeicher, der sich momentan im System befindet.
platform_type
Dieses Feld speichert den Typ der Plattform, der von einem Feld im HWRPB angenommen wird.
platform_name
Dieses Feld hält einen ganzzahligen Offset von der Basis des Baumwurzelknotens zu einer Zeichenfolge, die den Namen der Plattform repräsentiert.
primary_instance
Dieses Feld speichert die Partitions-ID der ersten Betriebssystem-Instanz.
first_tree
Dieses Feld hält den Offset vom Baumwurzelknoten zu ersten freien Byte des Speichervorrates, der für neue Knoten verwendet wird.
high_limit
Dieses Feld hält die höchste Adresse, an der sich ein gültiger Knoten innerhalb des Konfigurationsbaumes befinden kann. Es wird von Rückrufen verwendet um zu validieren, dass ein Handle zulässig ist.
lookaside
Dieses Feld ist das Handle einer verknüpften Liste von Knoten, die gelöscht wurden und die erneut beansprucht werden können. Wenn eine Gemein schaft oder eine Partition gelöscht werden, wird der Knoten in diese Liste verknüpft, wobei die Erzeugung einer neuen Partition oder Gemeinschaft diese Liste berücksichtigen wird, bevor eine Zuordnung aus dem freien Vorrat erfolgt.
available
Dieses Feld hält die maximale Zahl von Partitionen, die von der Plattform auf der Basis der Menge von Hardware-Ressourcen berechnet werden, die momentan verfügbar sind.
partitions
Dieses Feld hält einen Offset von der Basis des Wurzelknotens zu einer Anordnung von Handles. Jede Partitions-ID wird als Index in diese Anordnung verwendet, wobei das Partitionsknoten-Handle an der indizierten Stelle gespeichert wird. Wenn eine neue Partition erzeugt wird, wird diese Anordnung untersucht, um die erste Partitions-ID zu finden, die kein entsprechendes Partitionsknoten-Handle hat, wobei dieses Partitions-ID als ID für die neue Partition verwendet wird.
communities
Dieses Feld hält ebenfalls einen Offset von der Basis des Wurzelknotens zu einer Anordnung von Handles. Jede Gemeinschafts-ID wird als Index in diese Anordnung verwendet, wobei ein Gemeinschaftsknoten-Handle in der Anordnung gespeichert wird. Wenn eine neue Gemeinschaft erzeugt wird, wird diese Anordnung untersucht, um die erste Gemeinschafts-ID zu finden, die kein entsprechendes Gemeinschaftsknoten-Handle hat, wobei diese Gemeinschafts-ID als ID für die neue Gemeinschaft verwendet wird. Es kann nicht mehr Gemeinschaften als Partitionen geben, so dass die Größe der Anordnung auf der Basis der maximalen Zahl von Partitionen bemessen wird.
max_platform_partition
Dieses Feld hält die maximale Zahl von Partitionen, die gleichzeitig auf der Plattform existieren, selbst wenn zusätzliche Hardware hinzugefügt wird (potentiell eingelagert wird).
max_fragments
Dieses Feld hält eine plattformdefinierte Maximalzahl von Fragmenten, in die ein Speicherdeskriptor unterteilt werden kann. Es wird verwendet, um die Größe der Anordnung von Fragmenten im Speicherdeskriptor-Knoten zu bemessen.
max_desc
Dieses Feld hält die Maximalzahl von Speicherdeskriptoren für die Plattform.
APMP_id
Dieses Feld hält eine System-ID, die von der Systemsoftware eingestellt wird und im nicht flüchtigen RAM gespeichert wird.
APMP_id_pad
Dieses Feld hält die Auffüllbytes für die APMP-ID.
bindings
Dieses Feld hält einen Offset zu einer Anordnung von "Bindungen". Jeder Bindungseintrag beschreibt einen Typ eines Hardware-Knotens, der Knotentyp, der die Eltern sein müssen, die Konfigurationsbindung und die Affinitätsbindung für einen Knotentyp. Bindungen werden von der Software zur Bestimmung des Bezuges auf Knotentypen und der Konfigurations- sowie der Affinitätsregeln verwendet.
Eine Gemeinschaft bildet die Basis für die gemeinsame Nutzung von Ressourcen zwischen Partitionen. Wenngleich eine Hardware-Komponente einer beliebigen Partition in einer Gemeinschaft zugewiesen werden kann, erfolgt die tatsächliche gemeinsame Nutzung einer Vorrichtung, wie etwa des Speichers, lediglich innerhalb einer Gemeinschaft. Der Gemeinschaftsknoten 310 enthält einen Verweis zu einem Steuerabschnitt, der als APMP-Datenbank bezeichnet wird und es den Betriebssystem-Instanzen gestattet, den Zugriff und die Mitgliedschaft in der Gemeinschaft zu Zwecken der gemeinsamen Nutzung des Speichers und der Kommunikationen zwischen Instanzen zu steuern. Die APMP-Datenbank und die Erzeugung von Gemeinschaften wird im folgenden detailliert erläutert. Die Konfigurations-ID für die Gemeinschaft ist ein vorzeichenbehafteter ganzzahliger 16-Bit-Wert, der durch das Konsolen-Programm zugewiesen wird. Der ID-Wert ist niemals größer als die Maximalzahl von Partitionen, die auf der Plattform erzeugt werden können.
Ein Partitionsknoten, wie etwa der Knoten 312 oder 314, repräsentiert eine Sammlung von Hardware, die in der Lage ist, eine unabhängige Kopie des Konsolen-Programms und eine unabhängige Kopie eines Betriebssystems ablaufen zu lassen. Die Konfigurations-ID für diesen Knoten ist ein vorzeichenbehafteter, ganzzahliger 16-Bit-Wert, der durch die Konsole zugewiesen wird. Die ID ist niemals größer als die Maximalzahl von Partitionen, die auf der Plattform erzeugt werden können. Der Knoten hat folgende Definition:
Die definierten Felder haben folgende Definitionen:
hwrpb
Dieses Feld hält die physikalische Adresse des Hardware-Neustartparameterblocks für diese Partition. Um Änderungen am HWRPB zu minimieren, enthält der HWRPB keinen Verweis auf die Partition oder die Partitions-ID. Anstelle dessen enthalten die Partitionsknoten einen Verweise auf den HWRPB. Dies Systemsoftware kann dann die Partitions-ID der Partition bestimmen, auf der sie läuft, indem sie die Partitionsknoten für die Partition sucht, die die physikalische Adresse ihres HWRPB enthält.
incarnation
Dieses Feld hält einen Wert, der immer dann erhöht wird, wenn die primäre CPU der Partition einen Start- oder Neustartvorgang auf der Partition ausführt.
priority
Dieses Feld hält eine Partitionspriorität.
os_type
Dieses Feld hält einen Wert, der den Typ des Betriebssystems kennzeichnet, das in die Partition geladen wird.
partition_reserved_1
Dieses Feld ist für die zukünftige Verwendung reserviert.
instance_name_format
Dieses Feld hält einen Wert, der das Format der Instanznamens-Zeichenfolge beschreibt.
instance_name
Dieses Feld hält eine formatierte Zeichenfolge, die mit Hilfe des instance_name_format-Feldes übersetzt wird. Der Wert in diesem Feld gibt einen Pfadnamen einer hohen Ebene zur Betriebssystem-Instanz vor, die auf der Partition ausgeführt wird. Dieses Feld wird durch die Systemsoftware geladen und wird über Einschaltzyklen nicht gesichert. Das Feld wird beim Einschalten und bei der Partitionserzeugung und Partitionslöschung gelöscht.
Ein Systemaufbaublock-Knoten, wie etwa der Knoten 322 und 324, repräsentiert einen beliebigen Hardwareteil oder eine konzeptionelle Gruppierung, die von Systemplattformen mit modularen Aufbauten verwendet wird, wie es etwa in 2 gezeigt ist. Ein QBB (Quad-Aufbaublock) ist ein spezielles Beispiel eines SBB und entspricht Einheiten, wie etwa den Einheiten 100, 102, 104 und 106 in 1. Kinder der SBB-Knoten 322 und 324 enthalten Eingangs-/Ausgangs-Prozessorknoten 326 und 340.
Es wird davon ausgegangen, dass CPU-Knoten, wie etwa die Knoten 328–332 und 342–346, in der Lage sind als primäre CPU für den SMP-Betrieb zu arbeiten. Im dem seltenen Fall, bei dem eine CPU nicht primär sein kann, wird diese einen SUBTYPE-Code haben, der kennzeichnet, dass diese nicht als primäre CPU im SMP-Betrieb verwendet werden kann. Diese Informationen sind von Bedeutung, wenn Ressourcen konfiguriert werden, um eine neue Partition zu erzeugen. Der CPU-Knoten trägt zudem Informationen darüber, wo die CPU momentan ausgeführt wird. Bei der primären CPU für eine Partition ist das NODE_CPU_PRIMARY- Kennzeichen im NODE_FLAGS-Feld eingestellt. Der CPU-Knoten hat die folgende Definition:
Ein Speicherteilsystem-Knoten, wie etwa der Knoten 334 oder 348 ist ein "Pseudo"-Knoten, der Knoten gruppiert, die die physikalischen Speicher-Controller und die Zuweisungen des Speichers repräsentieren, die die Controller vorgeben. Die Kinder dieses Knotens bestehen aus einem oder mehreren Speicher-Controller-Knoten (wie etwa den Knoten 336 und 350), die die Konsole konfiguriert hat, um zusammen zu arbeiten (verschachtelt), und einem oder mehreren Speicher-Deskriptor-Knoten (wie etwa den Knoten 338 und 352), die physikalisch zusammenhängende Speicherbereiche beschreiben.
Ein Speicher-Controller-Knoten (wie etwa die Knoten 336 oder 350) wird verwendet, um eine physikalische Hardware-Komponente auszudrücken, wobei dessen Eigentümer normalerweise die Partition ist, die Fehler und die Initialisierung handhabt. Speicher-Controller können nicht Gemeinschaften zugewiesen werden, da sie eine spezielle Betriebssystem-Instanz für die Initialisierung, die Überprüfung und Fehler erfordern. Eine Speicherbeschreibung, die von einem Speicherdeskriptor-Knoten beschrieben ist, kann in "Fragmente" geteilt sein, um es unterschiedlichen Partitionen oder Gemeinschaften zu gestatten, spezielle Speicherbereiche innerhalb des Speicherdeskriptors zu besitzen. Der Speicher unterscheidet sich von anderen Hardware-Ressourcen dadurch, dass er gleichzeitig gemeinsam genutzt werden kann oder in "private" Bereiche zerlegt sein kann. Jeder Speicherdeskriptor-Knoten enthält eine Liste von Teilsatzbereichen, die es dem Speicher gestatten, unter den Partitionen aufgeteilt zu sein, wie auch zwischen Partitionen gemeinsam genutzt zu werden (einer Gemeinschaft zugehörig zu sein). Ein Speicherdeskriptor-Knoten (wie etwa die Knoten 338 oder 352) ist wie folgt definiert:
Der mem_info-Aufbau hat die folgende Definition:
Das mem_frag-Feld hält einen Offset von der Basis des Speicherdeskriptor-Knotens zu einer Anordnung von GCT_MEM_DESC-Strukturen, die folgende Definition haben:
Die Zahl von Fragmenten in einem Speicherbeschreibungs-Knoten (Knoten 338 oder 352) ist durch die Plattform-Firmware beschränkt. Dies erzeugt eine Obergrenze bei der Speicherunterteilung und beschränkt das unbegrenzte Wachstum des Konfigurationsbaumes. Die Software kann die Maximalzahl von Fragmenten aus dem max_fragments-Feld im Baumwurzelknoten 302 ermitteln (der oben beschrieben wurde), oder durch Aufrufen einer geeigneten Konsolen-Rückruffunktion, um den Wert zurückzugeben. Jedes Fragment kann einer beliebigen Partition zugewiesen werden, vorausgesetzt, dass die Konfigurationsbindung und die Zugehörigkeit des Speicherdeskriptors und die Speicherteilsystem-Knoten dies zulassen. Jedes Fragment enthält eine physikalisches Basisadressen-, Größen- und Besitzerkennzeichen, wie auch Kennzeichen, die den Typ der Verwendung kennzeichnen.
Um einen gemeinsam genutzten Speicherzugriff zu gestatten, müssen der Speicherteilsystem-Elternknoten und der Speicherdeskriptor-Knoten einer Gemeinschaft zugehörig sein. Die Fragmente innerhalb des Speicherdeskriptors können dann der Gemeinschaft zugehörig sein (gemeinsam genutzt werden), oder einer beliebigen Partition innerhalb der Gemeinschaft.
Fragmente können minimale Zuordnungsgrößen und Ausrichtungen aufweisen, die im Baumwurzelknoten 302 bereitgestellt sind. Der Basisspeicher für eine Partition (die Fragmente, in die die Konsole und das Betriebssystem geladen werden) kann eine größere Zuordnung und Ausrichtung haben als andere Fragmente (siehe die obige Baumwurzelknotendefinition). Wenn das Besitzerfeld des Speicherdeskriptor-Knotens eine Partition ist, können die Fragmente lediglich dieser Partition zugehörig sein.
4 zeigt den Konfigurationsbaum, der in 3 dargestellt ist, wenn er aus der Perspektive der Zugehörigkeit betrachtet wird. Das Konsolen-Programm für eine Partition überlässt die Zugehörigkeit und die Steuerung der Partitions-Ressourcen der Betriebssystem-Instanz, die auf dieser Partition läuft, wenn die primäre CPU für diese Partition die Ausführung beginnt. Das Konzept der "Zugehörigkeit" bestimmt, wie die Hardware-Ressourcen und die CPUs Software-Partitionen und Gemeinschaften zugewiesen werden. Der Konfigurationsbaum verfügt über Zugehörigkeitsverweise, die in 4 gezeigt sind und die Abbildung von Hardware-Vorrichtungen auf Software, wie etwa Partitionen (exklusiver Zugriff) und Gemeinschaften (gemeinsam genutzter Zugriff) bestimmen. Eine Betriebssystem-Instanz verwendet die Informationen im Konfigurationsbaum um zu bestimmen, auf welche Hardware-Ressourcen sie Zugriff hat, und die Neukonfigurationssteuerung.
Passive Hardware-Ressourcen, die keinen Besitzer haben, sind für die Verwendung nicht verfügbar, solange keine Zugehörigkeit eingerichtet ist. Sobald die Zugehörigkeit durch Verändern des Konfigurationsbaumes eingerichtet ist, können die Betriebssystem-Instanzen beginnen, diese Ressourcen zu verwenden. Macht eine Instanz eine anfängliche Anfrage, kann die Zugehörigkeit geändert werden, indem das besitzende Betriebssystem veranlasst wird, die Verwendung einer Ressource zu stoppen, oder indem ein Konsolen-Programm eine Tätigkeit ausführt, um die Verwendung einer Ressource in einer Partition zu stoppen, in der keine Betriebssystem-Instanz ausgeführt wird. Der Konfigurationsbaum wird anschließend abgeändert, um die Zugehörigkeit der Ressource auf eine weitere Betriebssystem-Instanz zu übertragen. Die Tätigkeit, die erforderlich ist, um ein Betriebssystem zu veranlassen, die Verwendung einer Hardware-Ressource zu stoppen, ist betriebssystemspezifisch und kann einen Neustart der Betriebssystem-Instanzen erfordern, die durch die Veränderung beeinflusst werden.
Um den Übergang einer Ressource von einem zugehörigen aktiven Zustand zu einem nicht zugehörigen und inaktiven Zustand zu verwalten, sind zwei Felder in jedem Knoten des Baumes vorgesehen. Das Besitzerfeld repräsentiert den Besitzer einer Ressource und wird mit dem Handle der besitzenden Softwarepartition oder Gemeinschaft geladen. Beim Starten eine APMP-Systems werden die Hard wareknoten aus den Inhalten des nicht flüchtigen Speichers geladen, um eine Ausgangskonfiguration einzurichten.
Um den Besitzer einer Ressource zu ändern, wird der Handle-Wert im Besitzerfeld der Hardware-Komponente und in den Besitzerfeldern beliebiger Abkömmlinge der Hardware-Komponente abgeändert, die an die Komponente durch ihre Konfigurations-Handles gebunden sind. Das current_owner-Feld repräsentiert den momentanen Benutzer der Ressource. Wenn das Besitzer- und das current_owner-Feld denselben Nicht-Null-Wert halten, ist die Ressource zugehörig und aktiv. Lediglich der Besitzer einer Ressource kann die Zuweisung der Ressource aufheben (das Besitzerfeld auf Null einstellen). Eine Ressource, die einen Null-Besitzer- und current_owner-Felder hat, ist nicht zugehörig und inaktiv. Lediglich Ressourcen, die Null-Besitzer und current-owner-Felder haben, können einer neuen Partition oder einer Gemeinschaft zugewiesen werden.
Wenn die Zuweisung einer Ressource aufgehoben wird, kann der Besitzer entscheiden, die Zuweisung des Besitzerfeldes oder sowohl der Besitzer- und der current_owner-Felder aufzuheben. Die Entscheidung basiert auf der Fähigkeit der besitzenden Betriebssystem-Instanz, die auf einer Partition läuft, die Verwendung der Ressource vor der Aufhebung der Zugehörigkeit zu unterbrechen. Für den Fall, bei dem ein Neustart erforderlich ist, um die Zugehörigkeit aufzugeben, wird das Besitzerfeld gelöscht, bleibt jedoch das current_owner-Feld unverändert. Wenn die Betriebssystem-Instanz neustartet, kann das Konsolen-Programm beliebige current_owner-Felder für Ressourcen löschen, die keinen Besitzer während der Initialisierung haben.
Während der Initialisierung modifiziert das Konsolen-Programm das current_owner-Feld, um das Besitzerfeld für einen beliebigen Knoten anzupassen, von dem es der Besitzer ist und für das das current_owner-Feld Null ist. Die Systemsoftware sollte lediglich Hardware verwenden, von der sie der momentane Besitzer ist. Für den Fall einer Aufhebung der Zugehörigkeit einer Ressource, die einer Gemeinschaft zugehörig ist, liegt es in der Verantwortlichkeit der Systemsoftware, den Übergang zwischen den Zuständen zu verwalten. Bei einigen Ausführungsformen, kann eine Ressource an eine weitere Partition verliehen werden.

In diesem Zustand sind das Besitzer- und das current_owner-Feld beide gültig, jedoch nicht gleich. Die folgenden Tabelle fasst die möglichen Ressourcezustände und die Werte der Besitzer- und current_owner-Felder zusammen: TABELLE 1

Besitzerfeldwert	current_owner-Feldwert	Ressourcen-Zustand
Keiner	Keiner	nicht zugehörig und inaktiv
Keiner	Gültig	nicht zugehörig aber weiterhin aktiv
Gültig	Keiner	zugehörig, noch nicht aktiv
Gültig	Gleich dem Besitzer	zugehörig und aktiv
Gültig	Nicht Gleich dem Besitzer	ausgeliehen

Da die CPUs aktive Vorrichtungen sind und eine gemeinsame Benutzung von CPUs bedeutet, dass eine CPU im Kontext einer Partition eine Ausführung durchführen könnte, die nicht ihr "Besitzer" sein könnte, unterscheidet sich die Zugehörigkeit einer CPU von der Zugehörigkeit einer passiven Ressource. Der CPU-Knoten im Konfigurationsbaum stellt zwei Felder bereit, die kennzeichnen, von welcher Partition eine CPU nominal "besessen" wird und auf welcher Partition die CPU momentan ihre Ausführung durchführt. Das Besitzerfeld enthält einen Wert, der die nominale Zugehörigkeit der CPU oder genauer gesagt die Partition kennzeichnet, auf der die CPU zu Beginn die Ausführung bei einem Systemstart durchführt.
Bis eine anfängliche Zugehörigkeit eingerichtet ist (d. h. wenn das Besitzerfeld nicht zugewiesen ist), befinden sich die CPUs in einem HWRPB-Zusammenhang, der von der Master-Konsole festgelegt wird, wobei jedoch das für den HWRPB verfügbare Bit für die CPU in einem beliebigen HWRPB nicht eingestellt wird. Diese Kombination verhindert, dass sich die CPU einer Betriebssystem-Instanz während des SMP-Betriebs anschließt. Wenn die Zugehörigkeit einer CPU eingerichtet ist (das Besitzerfeld wir mit einem gültigen Partitions-Handle gefüllt), wird die CPU, sofern es erforderlich ist, zur besitzenden Partition migrieren, wird sie das verfügbare Bit im HWRPB einstellen, der dieser Partition zugeordnet ist, und wird sie anfragen, sich am SMP-Betrieb der Instanz zu beteiligen, die auf dieser Partition läuft, oder sich am Konsolen-Programm in der SMP-Betriebsart zu beteiligen. Die Kombination der vorliegenden und der verfügbaren Bits im HWRPB teilen der Betriebssystem-Instanz mit, dass die CPU für die Verwendung im SMP-Betrieb verfügbar ist, wobei die Betriebssystem-Instanz diese Bits verwenden kann, um geeignete Datenstrukturen je CPU aufzubauen und eine Nachricht zur CPU zu senden, um sie aufzufordern, am SMP-Betrieb teilzunehmen.
Wenn eine CPU das verfügbare Bit in einem HWRPB einstellt, gibt sie ebenfalls einen Wert in das current_owner-Feld in ihrem entsprechenden CPU-Knoten im Konfigurationsbaum ein. Der current_owner-Feldwert ist das Handle der Partition, auf der die CPU das aktive HWRPB-Bit eingestellt hat, und ist in der Lage am SMP-Betrieb teilzunehmen. Das current_owner-Feld für eine CPU wird lediglich durch das Konsolen-Programm eingestellt. Wenn eine CPU von einer Partition zu einer weiteren migriert, oder in einen nicht zugewiesenen Zustand angehalten wird, wird das current_owner-Feld zu selben Zeit gelöscht (oder zum neuen Partitions-Handle-Wert geändert), zu der das verfügbare Bit im HWRPB gelöscht wird. Das current_owner-Feld sollte nicht direkt durch die Systemsoftware geschrieben werden und spiegelt lediglich wider, bei welchem HWRPB das verfügbare Bit für die CPU eingestellt ist.
Während der Laufzeit kann eine Betriebssystem-Instanz vorübergehend eine CPU an eine weitere Partition "ausleihen", ohne die nominelle Zugehörigkeit der CPU zu ändern. Das herkömmliche SMP-Konzept der Zugehörigkeit unter Verwendung des vorliegenden HWRPB und der verfügbaren Bits wird verwendet, um den momentanen Ausführungskontext der CPU durch Abändern des HWRPB und des Konfigurationsbaumes bei atomischen Vorgängen widerzuspiegeln. Das current_owner-Feld kann weiterhin von der Systemsoftware auf einer der Partitionen verwendet werden um zu bestimmen, auf welcher Partition die CPU momentan die Ausführung durchführt (andere Instanzen können den Ort einer speziellen CPU bestimmen, indem sie den Konfigurationsbaum untersuchen).
Es besteht zudem die Möglichkeit, die Zuweisung einer CPU aufzuheben, und in einen Zustand zurückzukehren, in dem das verfügbare Bit in einem beliebigen HWRPB nicht eingestellt ist und das current_owner-Feld im Konfigurationsbaum-Knoten für die CPU gelöscht ist. Dies wird dadurch bewerkstelligt, dass die Ausführung der CPU angehalten und das Konsolen-Programm veranlasst wird, das Besitzerfeld im Konfigurationsbaum-Knoten wie auch das current_owner-Feld und das verfügbare HWRPB-Bit zu löschen. Die CPU führt anschließend die Ausführung im Konsolenmodus durch und pollt das Besitzerfeld, das darauf wartet, dass ein gültiges Partitions-Handle in dieses geschrieben wird. Die Systemsoftware kann anschließend einen neuen Besitzer einrichten und die CPU kann eine Ausführung in der neuen Partition beginnen.
Beispielhafte Zugehörigkeitsverweise sind in 4 mit Pfeilen dargestellt. Jedem der Knoten in 4, der einem ähnlichen Knoten in 3 entspricht, ist eine entsprechende Zahl gegeben. Beispielsweise ist der Software-Wurzelknoten, der in 3 als Knoten 306 gekennzeichnet ist, in 4 mit 406 gekennzeichnet. In ähnlicher Weise sind die Systemaufbaublöcke 1 und 2 (422 und 425) der Gemeinschaft 410 zugehörig. In ähnlicher Weise sind die Partitionen 412 und 414 ebenfalls der Gemeinschaft 410 zugehörig.
Zur Partition 412 gehören die CPUs 428 bis 432 und der I/O-Prozessor 426. Der Speicher-Controller 436 ist ebenfalls Teil der Partition 1 (412). In ähnlicher Weise besitzt die Partition 2 (414) die CPUs 442–446, den I/O-Prozessor 440 und den Speicher-Controller 450.
Der gemeinsame oder gemeinsam genutzte Speicher im System besteht aus den Speicher-Teilsystemen 434 und 448 sowie die Speicherdeskriptoren 438 und 452. Diese sind der Gemeinschaft 410 zugehörig. Somit beschreibt 4 die Anordnung des Systems, wie es für die Betriebssystem-Instanzen erscheinen würde.
Betriebssystem-Eigenschaften
Wie es zuvor erwähnt wurde, kann das dargestellte Computersystem mit zahlreichen unterschiedlichen Betriebssystemen auf unterschiedlichen Partitionen arbeiten. Es müssen jedoch ggf. herkömmliche Betriebssysteme in bestimmten Aspekten abgeändert werden, um sie mit dem System der Erfindung kompatibel zu machen, abhängig davon, wie das System konfiguriert ist. Einige Beispielabänderungen für die beispielhafte Ausführungsform sind im folgenden aufgeführt:

1. Instanzen müssen ggf. abgeändert werden, um einen Mechanismus zum Wählen einer "primären" CPU in der Partition zu enthalten, um die Konsole ablaufen zu lassen und ein Ziel für die Kommunikation von anderen Instanzen zu sein. Die Auswahl einer primären CPU kann auf herkömmliche Art und Weise mit Hilfe von Entscheidungsmechanismen oder anderen herkömmlichen Vorrichtungen erfolgen.
2. Jede Instanz kann ggf. Abänderungen erfordern, die es ihr gestatten, mit dem Konsolen-Programm zu kommunizieren und zusammenzuwirken, das für die Erzeugung eines Konfigurationsdatenblocks verantwortlich ist, der die Ressourcen beschreibt, die für die Partition verfügbar sind, auf der die Instanz läuft. Beispielsweise sollte diese Instanz nicht die zugrundeliegende Hardware überprüfen, um zu bestimmen, welche Ressourcen für die Verwendung durch die Instanz verfügbar sind. Wird ihr anstelle dessen ein Konfigurationsdatenblock zugeführt, der beschreibt, auf welche Instanzen diese Ressource zugreifen darf, muss sie mit den festgelegten Ressourcen arbeiten.
3. Eine Instanz muss ggf. in der Lage sein, eine willkürliche physikalische Adresse zu beginnen und kann ggf. nicht in der Lage sein, eine beliebige physikalische Adresse zu reservieren, um einen Konflikt mit anderen Betriebssystemen zu vermeiden, die an dieser speziellen Adresse laufen.
4. Eine Instanz muss ggf. in der Lage sein, mehrere willkürliche physikalische Löcher in ihrem Adressraum zu unterstützen, sofern sie Teil einer Systemkonfiguration ist, in der Speicher zwischen Partitionen gemeinsam genutzt wird. Darüber hinaus muss eine Instanz ggf. mit physikalischen Löchern in ihrem Adressraum umgehen, um einen "Hot Inswap" des Speichers zu unterstützen.
5. Eine Instanz muss ggf. Nachrichten weiterleiten und Meldungen empfangen, dass neue Ressourcen für Partitionen und Instanzen verfügbar sind. Insbesondere wird ein Protokoll benötigt, um eine Instanz zu informieren, nach einer neuen Ressource zu suchen. Andernfalls könnte die Instanz niemals erkennen, dass die Ressource eingetroffen ist und zur Verwendung bereit ist.
6. Eine Instanz muss ggf. in der Lage sein, vollständig innerhalb ihres "privaten Speichers" abzulaufen, wenn sie in einem System verwendet wird, in dem Instanzen Speicher nicht gemeinsam nutzen. Alternativ muss eine Instanz ggf. in der Lage sein, physikalischen "gemeinsam genutzten Speicher" zur Kommunikation oder gemeinsamen Nutzung mit anderen Instanzen zu verwenden, die innerhalb des Computers ablaufen, sofern die Instanz Teil eines Systems ist, in dem Speicher gemeinsam genutzt wird. In einem derartigen System muss eine Instanz ggf. in der Lage sein, einen physikalischen "gemeinsam genutzten Speicher", wie er im Konfigurationsbaum gekennzeichnet ist, in ihren virtuellen Adressraum und die virtuellen Adressräume der "Prozesse" abzubilden, die innerhalb dieser Betriebssystem-Instanz ablaufen.
7. Jede Instanz muss ggf. über einen Mechanismus verfügen, um eine weitere CPU im Computersystem zu kontaktieren, um mit dieser zu kommunizieren.
8. Eine Instanz muss ggf. in der Lage sein, andere CPUs zu erkennen, die mit ihren Tätigkeiten kompatibel sind, selbst wenn die CPUs momentan nicht ihrer Partition zugeordnet sind. Die Instanz muss beispielsweise ggf. in der Lage sein, CPU-Parameter, wie etwa die Konsolen-Korrekturzahl und die Taktzahl, zu bestätigen um zu bestimmen, ob sie mit dieser CPU laufen kann, sofern die CPU der Partition zugeordnet wurde, auf der die Instanz läuft.

Ändern des Konfigurationsbaumes
Jedes Konsolen-Programm stellt eine Anzahl von Rückruffunktionen bereit, um es der zugeordneten Betriebssystem-Instanz zu gestatten, die Konfiguration des APMP-Systems dadurch zu ändern, dass beispielsweise eine neue Gemeinschaft oder Partition erzeugt wird oder die Zugehörigkeit der Fragmente geändert wird. Darüber hinaus stellen weitere Rückruffunktionen die Fähigkeit bereit, eine Gemeinschaft oder Partition zu entfernen oder einen Vorgang auf einer neu erzeugten Partition zu starten.
Rückruffunktionen bewirken jedoch nicht, dass beliebige Änderungen in den laufenden Betriebssystem-Instanzen stattfinden. Auf beliebige Änderungen, die am Konfigurationsbaum vorgenommen werden, muss von jeder Instanz reagiert werden, die von der Änderung betroffen ist. Die Art der Reaktion, die in einer Instanz erfolgen muss, wenn der Konfigurationsbaum verändert wird, ist eine Funktion des Typs der Änderung und der Betriebssystem-Instanzfähigkeiten. Beispielsweise kann das Bewegen eines Eingangs-/Ausgangs-Prozessors von einer Partition zu einer weiteren erfordern, dass beide Partitionen neustarten. Das Ändern der Speicherzuordnung von Fragmenten kann andererseits von einer Betriebssysteminstanz gehandhabt werden, ohne dass ein Neustart erforderlich ist.
Die Konfiguration eines APMP-Systems bedingt die Erzeugung von Gemeinschaften und Partitionen und die Zuweisung von nicht zugewiesenen Komponenten. Wenn eine Komponente von einer Partition zu einer weiteren Partition bewegt wird, entfernt der momentane Besitzer sich selbst als Besitzer von der Ressource und kennzeichnet anschließend den neuen Besitzer der Ressource. Der neue Besitzer kann anschließend die Ressource verwenden. Wenn eine Instanz, die auf einer Partition läuft, eine Komponente freigibt, muss die Instanz nicht länger auf die Komponente zugreifen. Diese einfache Vorgehensweise eliminiert die komplexe Synchronisation, die erforderlich ist, um einen unbemerkten Raub einer Komponente von einer Instanz und mögliche Race-Bedingungen beim Starten einer Instanz während einer Neukonfiguration zuzulassen.
Sobald eine Initialisierung erfolgt ist, werden die Konfigurationsbaum-Knoten niemals gelöscht oder bewegt, d. h. ihre Handles werden immer gültig sein. Somit können Hardware-Knotenadressen von der Software in den Cache geladen werden. Rückruffunktionen, die vorgeben, eine Partition oder eine Gemeinschaft zu löschen, löschen nicht tatsächlich den zugeordneten Knoten oder entfernen diesen aus dem Baum, sondern kennzeichnen anstelle dessen den Knoten als NICHT VERFÜGBAR und löschen die Zugehörigkeitsfelder einer beliebigen Hardware-Ressource, die der Software-Komponente zugehörig war.
Um Änderungen am Konfigurationsbaum zu synchronisieren, behält der Wurzelknoten des Baumes zwei Zähler (transient_level und current_level) bei. Der transient_level-Zähler wird bei Beginn einer Aktualisierung des Baumes erhöht, und der current_level-Zähler wird erhöht, wenn die Aktualisierung abgeschlossen ist. Die Software kann diese Zähler verwenden um zu bestimmen, wann eine Änderung aufgetreten ist, oder am Baum auftritt. Wenn eine Aktualisierung durch eine Konsole abgeschlossen ist, kann ein Interrupt für sämtliche CPUs im APMP-System erzeugt werden. Dieser Interrupt kann verwendet werden, um die Systemsoftware zu veranlassen, ihren Zustand auf der Basis von Änderungen am Baum zu aktualisieren.
Erzeugung eines APMP-Computersystems
5 ist ein Flussdiagramm, das einen Überblick über die Ausbildung des beispielhaften adaptiv partitionierten Multiprozessor-(APMP-)Computersystems darstellt. Die Routine beginnt bei Schritt 500 und schreitet zu Schritt 502 fort, bei dem ein Master-Konsolen-Programm gestartet wird. Wenn das APMP-Computer-System beim Starten erzeugt wird, wird die CPU, auf der die Master-Konsole läuft, von einem vorbestimmten Mechanismus, wie etwa einer Entscheidungsinstanz oder einem weiteren Hardware-Mechanismus, gewählt. Wird das APMP- Computersystem auf einer Hardware erzeugt, die bereits läuft, lässt eine CPU auf der ersten Partition, die versucht am (nicht vorhandenen) System teilzunehmen, das Master-Konsolen-Programm ablaufen, wie es im folgenden erläutert wird.
Als nächstes prüft in Schritt 504 das Master-Konsolen-Programm die Hardware und erzeugt den Konfigurations-Baum in Schritt 506, wie es oben erläutert wurde. Gibt es mehr als eine Partition im APMP-System beim Starten, wird jede Partition initialisiert und deren Konsolen-Programm gestartet (Schritt 508).
Schließlich wird eine Betriebssystem-Instanz auf wenigstens einer der Partitionen gestartet, wie es in Schritt 510 gekennzeichnet ist. Die erste zu startende Betriebssystem-Instanz erzeugt eine APMP-Datenbank und fügt die Einträge ein, wie es unten beschrieben ist. APMP-Datenbanken speichern Informationen, die sich auf den Zustand aktiver Betriebssystem-Instanzen im System beziehen. Die Routine endet anschließend bei Schritt 512. Es wird darauf hingewiesen, dass eine Instanz nicht an einem APMP-System teilnehmen muss. Die Instanz kann zu einem Zeitpunkt, der ausreichend lange nach dem Starten auftritt, eine Teilnahme oder nicht Teilnahme wählen. Jene Instanzen, die teilnehmen, bilde einen "gemeinsam nutzenden Satz". Die erste Instanz, die entscheidet, an einer Teil-Einrichtung teilzunehmen, ist für den Inhalt und den Zugriff auf ihr eigenes Segment verantwortlich.
Der anfängliche Header-Abschnitt einer APMP-Datenbank ist der erste Teil der APMP-Datenbank, die durch eine teilnehmende Betriebssystem-Instanz abgebildet wird. Auf Teile des Headers wird zugegriffen, bevor die Instanz am gemeinsam nutzenden Teil teilgenommen hat und tatsächlich bevor der Instanz bekannt ist, dass das APMP-Computersystem existiert.
Der Header-Abschnitt enthält:

1. ein Mitglieds- und Erzeugungssynchronisations-Quadword
2. eine Computersystemsoftware-Version
3. Zustandsinformationen, eine Erzeugungszeit, eine Inkarnationszahl, etc.
4. einen Verweis (Offset) zu einer Mitgliedsmaske
5. eine Absturz-Instanz, Absturz-Bestätigungsbits, etc.
6. Validierungsmasken, die ein Bit für jeden Dienst enthalten
7. Speicher-Abbildungsinformationen (Seitenrahmenzahl-Informationen) für die gesamte APMP-Datenbank
8. Offset-/Längen-Paare, die jedes der Dienstsegmente (Längen in Bytes, gerundet zu Seiten und volle Seiten von Offsets) beschreiben, enthaltend: gemeinsam genutzte Speicherdienste CPU-Kommunikationsdienste Mitgliedsdienste (sofern erforderlich) Verriegelungsdienste

Die Anordnung von Knotenblöcken ist durch eine Systempartitions-ID indiziert (eine pro Instanz, die auf der aktuellen Plattform möglich ist), wobei jeder Block enthält:
eine Instanz-Software-Version
eine Interruptgrund-Maske
einen Instanzzustand
eine Instanzinkarnation
einen Instanz-Heartbeat
einen Instanzmitgliedschaft-Zeitstempel
eine Kleiner-Bruder-Instanz-ID und Inaktiv-Zeit; eine Großer-Bruder-Instanz-ID
ein Bit für eine erfolgte Instanzvalidierung.
Eine APMP-Datenbank ist im gemeinsam genutzten Speicher gespeichert. Der zu Beginn fixierte Abschnitt von N physikalisch zusammenhängenden Seiten belegt die ersten N Seiten eines von zwei Speicherbereichen, die durch die erste Instanz zugeordnet sind, um an der anfänglichen Partitionierung der Hardware teilzunehmen. Die Instanz weist die Konsole an, die beginnenden physikalischen Adressen dieser Bereiche im Konfigurationsbaum zu speichern. Der Zweck der Zuordnung zweier Bereiche besteht darin, eine Ausfallsicherung im Falle eines Hardware-Speicherfehlers zuzulassen. Die Speicherverwaltung ist für die Abbildung des physikalischen Speichers in den virtuellen Adressraum für die APMP-Datenbank verantwortlich.
Die detaillierten Tätigkeiten, die von einer Betriebssystem-Instanz ausgeführt werden, sind in 6 dargestellt. Insbesondere wenn eine Betriebssystem-Instanz ein Mitglied eines gemeinsam nutzenden Satzes werden will, muss sie vorbereitet sein, das APMP-Computersystem zu erzeugen, sofern es die erste Instanz ist, die versucht, an einem nicht existierenden System "teilzunehmen". Damit die Instanz bestimmen kann, ob ein APMP-System bereits vorhanden ist, muss die Instanz in der Lage sein, den Zustand des gemeinsam genutzten Speichers zu untersuchen, wie es oben beschrieben ist. Weiterhin muss sie in der Lage sein, sich mit anderen Instanzen zu synchronisieren, die es ggf. versuchen, am APMP-System und am gemeinsam nutzenden Satz gleichzeitig teilzunehmen, um sich entgegenstehende Erzeugungsversuche zu vermeiden. Die Master-Konsole erzeugt den Konfigurationsbaum, wie es oben beschrieben wurde. Anschließend wird ein Speicherbereich von der ersten oder primären Betriebssystem-Instanz für den Start initialisiert, wobei dieser Speicherbereich für eine APMP-Datenbank verwendet werden kann.
Abbilden des APMP-Datenbank-Headers
Das Ziel der anfänglichen Tätigkeiten, die von sämtlichen Betriebssysteminstanzen ausgeführt werden, besteht darin, den Header-Abschnitt der APMP-Datenbank abzubilden und eine primitive Zwischeninstanz-Interrupt-Handhabung zu initialisieren, um die Grundlage für die Entscheidung einer Erzeugung oder eine Teilnahme zu schaffen. Die verwendete Routine ist in 6 gezeigt, die bei Schritt 600 beginnt. Die erste Tätigkeit, die von jeder Instanz ausgeführt wird (Schritt 602) besteht darin, eine Speicherverwaltung einzuschalten, um das anfängliche Segment der APMP-Datenbank abzubilden, wie es oben beschrieben ist. Gleichzeitig wird die Anordnung der Knotenblöcke im zweiten Datenbankabschnitt ebenfalls abgebildet. Die Speicherverwaltung bildet das anfängliche und das zweite Segment der APMP-Datenbank in den primären Betriebssystem-Adressraum ab und gibt die Startadresse sowie die Länge zurück. Die Instanz informiert die Konsole daraufhin, den Ort und die Größe der Segmente im Konfigurationsbaum zu speichern.
Als nächstes wird in Schritt 604 die anfängliche virtuelle Adresse der APMP-Datenbank verwendet, um es der Initialisierungsroutine zu gestatten, die Interrupt-Grund-Masken im Knotenblock zu nullen, der der aktuellen Instanz zugeordnet ist.
Ein Null-Ausgangswert wird anschließend für das Heartbeat-Feld für die Instanz im Knotenblock und andere Knotenblock-Felder gespeichert. In einigen Fällen war die Instanz, die versucht, ein neues APMP-Computersystem zu erzeugen, zuvor ein Mitglied eines APMP-Systems und zog sich nicht aus dem APMP-System zurück. Wenn diese Instanz neustartet, bevor die anderen Instanzen diese entfernt haben, werden deren Bits weiterhin in der Systemmitgliedsmaske "ein" sein. Andere ungewöhnliche oder fehlerhafte Fälle können ebenfalls zu "Ausschuss" führen, der in der Systemmitgliedsmaske gespeichert ist.
Als nächstes wird in Schritt 608 die virtuelle Adresse (VA) der APMP-Datenbank in einer privaten Zelle gespeichert, die von einer Zwischenprozessor-Interrupt-Handhabungseinrichtung untersucht wird. Die Handhabungseinrichtung untersucht diese Zelle, um zu bestimmen, ob die Interrupt-Grund-Maske pro Instanz im APMP-Datenbank-Header auf zu erledigende Arbeit geprüft werden soll. Ist diese Zelle Null, wird die APMP-Datenbank nicht abgebildet und von der Handhabungseinrichtung nichts weiter unternommen. Wie es zuvor beschrieben wurde, wird die gesamte APMP-Datenbank, einschließlich dieser Maske initialisiert, so dass die Handhabungseinrichtung nichts unternimmt, bevor die Adresse gespeichert ist. Darüber hinaus kann eine Taktunterbrechungs-Handhabungseinrichtung dieselbe private Zelle untersuchen, um zu ermitteln, ob das instanzspezifische Heartbeat-Feld für diese Instanz im geeigneten Knotenblock erhöht werden soll. Ist die private Zelle null, erhöht die Interrupt-Handhabungseinrichtung nicht das Heartbeat-Feld.
An diesem Punkt wird die Routine beendet (Schritt 610) und kann auf den APMP-Datenbank-Header zugegriffen werden und ist die teilnehmende Instanz in der Lage, den Header zu untersuchen und zu entscheiden, ob das APMP-Computersystem nicht existiert und somit die Instanz dieses erzeugen muss, oder ob die Instanz an einem bereits bestehenden APMP-System teilnehmen wird.
Sobald der APMP-Header abgebildet ist, wird der Header untersucht, um zu bestimmen, ob ein APMP-Computersystem eingeschaltet ist und funktioniert, und wenn nicht, ob die aktuelle Instanz die APMP-Datenbank initialisieren und das APMP-Computersystem erzeugen soll. Das Problem der Teilnahme an einem bestehenden APMP-System wird schwieriger, wenn beispielsweise das APMP-Computersystem zu einem Zeitpunkt erzeugt wurde, nun jedoch keine Mitglieder hat, oder wenn das APMP-System nach einem Fehler neu ausgebildet wird. In diesem Fall ist der Zustand des APMP-Datenbankspeichers im voraus nicht bekannt und ein einfacher Speichertest nicht ausreichend. Eine Instanz, die versucht, an einem möglicherweise vorhandenen APMP-System teilzunehmen, muss in der Lage sein zu bestimmen, ob ein APMP-System existiert oder nicht, und wenn dies nicht existiert, muss die Instanz in der Lage sein, ein neues APMP-System ohne Störung durch andere Instanzen zu erzeugen. Diese Störung könnte aus Threads entstehen, die entweder in derselben Instanz oder einer weiteren Instanz ablaufen.
Um eine derartige Störung zu vermeiden, wird eine Erzeugungs-/Teilnahme-Entscheidung getroffen, indem zuerst die APMP-Datenbank verriegelt und anschließend der APMP-Header untersucht wird um zu bestimmen, ob es ein funktionierendes APMP-Computersystem gibt. Gibst es ein ordnungsgemäß funktionierendes APMP-System, dann nimmt die Instanz am System teil und löst die Verriegelung der APMP-Datenbank. Gibt es kein APMP-System, oder gibt es ein APMP-System, das jedoch nicht funktioniert, dann erzeugt die Instanz alternativ ein neues APMP-System mit sich selbst als Mitglied und löst die Verriegelung der APMP-Datenbank.
Gibt es offenbar ein APMP-System im Übergang, dann wartet die Instanz solange, bis das APMP-System wieder in Betrieb oder tot ist und schreitet anschließend fort, wie es oben beschrieben ist. Kann kein System erzeugt werden, schlägt die Teilnahme fehl.
Erzeugen eines neuen APMP-Computer-Systems
Unter der Voraussetzung, dass eine neues APMP-System erzeugt werden muss, ist die Erzeuger-Instanz für die Zuordnung des Restes der APMP-Datenbank, die Initialisierung des Headers und das Aufrufen der Systemdienste verantwortlich. Vorausgesetzt, die APMP-Datenbank ist verriegelt, wie es oben beschrieben wurde, werden die folgenden Schritte von der Erzeuger-Instanz ausgeführt, um das APMP-System zu initialisieren (diese Schritte sind in 7A und 7B gezeigt):
Schritt 702 die Erzeuger-Instanz stellt den APMP-Systemzustand und dessen Knotenblock auf den Zustand "Initialisieren" ein
Schritt 704 die Erzeuger-Instanz ruft eine Größenroutine für jeden Systemdienst mit der Adresse seines Längenfeldes im Header auf.
Schritt 706 die resultierenden Längenfelder werden summiert und die Erzeugerinstanz ruft eine Speicherverwaltung auf, um Raum für die gesamte APMP-Datenbank zuzuordnen, indem eine neue Abbildung erzeugt und die alte Abbildung gelöscht wird.
Schritt 708 die Erzeuger-Instanz füllt die Offsets der Anfänge jedes Systemdienst-Segmentes
Schritt 710 Die Initialisierungsroutine für jeden Dienst wird mit virtuellen Adressen der APMP-Datenbank, mit dem Dienst-Segment und der Segmentlänge aufgerufen
Schritt 712 Die Erzeuger-Instanz initialisiert eine Mitgliedsmaske, um sich selbst zum einzigen Mitglied zu machen und erhöht die Inkarnationszahl. Anschließend stellt sie die Erzeugungszeit, die Softwareversion und andere Parameter ein.
Schritt 714 Die Instanz stellt sich anschließend als eigener großer und kleiner Bruder (für Hartbeat-Überwachungszwecke, wie es unten beschrieben wird) ein.
Schritt 716 Anschließend fügt sich die Instanz in ihren Instanzzustand als "Mitglied" und dem APMP-Systemzustand als "in Betrieb" ein.
Schritt 718 Schließlich löst die Instanz die Verriegelung der APMP-Datenbank.
Die Routine endet anschließend in Schritt 720.
Teilnahme an einem bestehenden APMP-Computersystem
Vorausgesetzt, eine Instanz hat eine verriegelte APMP-Datenbank, werden die folgenden Schritte von der Instanz ausgeführt, um ein Mitglied eines existierenden APMP-Systems zu werden (das in 8A und 8B gezeigt ist):
Schritt 802 Die Instanz stellt sicher, dass ihr Instanzname einzigartig ist. Hat ein weiteres aktuelles Mitglied den von der Instanz vorgeschlagenen Namen, wird die Teilnahme abgebrochen.
Schritt 804 Die Instanz stellt die APMP-Systemzustand und ihren Knotenblockzustand auf "Instanz-Teilnahme" ein.
Schritt 806 Die Instanz ruft eine Speicherverwaltungsroutine ab, um den variablen Abschnitt der APMP-Datenbank in ihren lokalen Adressraum abzubilden.
Schritt 808 Die Instanz ruft Systemteilnahmeroutinen für jeden Systemdienst mit den virtuellen Adressen der APMP-Datenbank und ihrem Segment sowie ihrer Segmentlänge ab
Schritt 810 Melden sämtliche Dienstteilnahmeroutinen einen Erfolg, wird die Instanzteilnahmeroutine fortgeführt. Schlägt eine beliebige Dienstteilnahmeroutine fehl, muss der Instanzteilnahmevorgang erneut beginnen und möglicherweise ein neues APMP-Computersystem erzeugen.
Schritt 812 Vorausgesetzt, es wurde in Schritt 810 ein Erfolg erzielt, fügt sich die Instanz selbst zur Systemmitgliedsmaske hinzu.
Schritt 814 Die Instanz wählt einen großen Bruder, um ihren Instanzzustand zu überwachen, wie es unten ausgeführt ist.
Schritt 816 Die Instanz fügt sich in ihren Instanzzustand als "Mitglied" ein und stellt ein lokales Mitgliedskennzeichen ein.
Schritt 818 Die Instanz löst die Verriegelung der Konfigurationsdatenbank.
Die Routine endet anschließend in Schritt 820.
Der Verlust einer Instanz entweder durch eine Inaktivitätszeitüberschreitung oder einen Absturz wird mit Hilfe eines "Heartbeat"-Mechanismus erfasst, der in der APMP-Datenbank eingesetzt wird. Instanzen versuchen minimales Prüfen und Bereinigen und informieren den Rest des APMP-Systems während eines Instanzenabsturzes. Ist dies nicht möglich, erfassen die Systemdienste das Verschwinden einer Instanz über einen Software-Heartbeat-Mechanismus. Insbesondere wird ein "Heartbeat"-Feld in der APMP-Datenbank für jede aktive Instanz zugeordnet. In dieses Feld wird durch die entsprechende Instanz in Zeitintervallen geschrieben, die kürzer sind als ein vorbestimmter Wert, wie etwa alle zwei Millisekunden.
Eine beliebige Instanz kann das Heartbeat-Feld einer beliebigen anderen Instanz untersuchen, um eine direkte Unterscheidung für einen speziellen Zweck zu treffen. Eine Instanz liest das Heartbeat-Feld einer weiteren Instanz durch zweifaches Lesen ihres Heartbeat-Feldes, getrennt durch eine Zeitdauer von zwei Millisekunden. Wird das Heartbeat-Feld zwischen den beiden Lesevorgängen nicht erhöht, wird die Instanz als inaktiv betrachtet (vergangen, angehalten bei Control-P, oder an oder über der Takt-Interrupt-Prioritätsebene hängen geblieben). Bleibt die Instanz für eine vorbestimmte Zeit inaktiv, dann wird die Instanz als tot oder nicht von Belang betrachtet.
Darüber hinaus wird eine spezielle Anordnung verwendet, um sämtliche Instanzen zu beobachten, da nicht jede Instanz jede andere Instanz überwachen kann, insbesondere dann, wenn das APMP-System an Größe gewinnt. Diese Anordnung verwendet ein "Großer-Bruder-Kleiner-Bruder"-Schema. Insbesondere wenn eine Instanz am APMP-System teilnimmt, bevor die Verriegelung der APMP-Datenbank gelöst wird, wählt sie eines der aktuellen Mitglieder als ihren großen Bruder und Überwachung der teilnehmenden Instanz. Die teilnehmende Instanz übernimmt zunächst Aufgaben des großen Bruders für ihren gewählten kleinen Bruder des großen Bruders und weist sich selbst anschließend als neuen kleinen Bruder der gewählten Instanz zu. Wenn im Gegensatz dazu eine Instanz das APMP-Computersystem verlässt, während es weiterhin in Betrieb ist, so dass es in der Lage ist, eine Ausstiegsverarbeitung auszuführen, und während es die Verriegelung der APMP-Datenbank beibehält, weist sie die Aufgaben ihres großen Bruders ihrem kleinen Bruder zu, bevor sie die Erhöhung ihres Heartbeats stoppt.
Zu jedem Taktschlag nach der Erhöhung ihres eigenen Heartbeats, liest jede Instanz den Heartbeat ihres kleinen Bruders und vergleicht diesen mit dem Wert, der beim letzten Taktschlag gelesen wurde. Ist der neue Wert größer oder hat sich die ID des kleinen Bruders geändert, wird der kleine Bruder als aktiv erachtet. Sind jedoch die ID des kleinen Bruders und der Heartbeat-Wert identisch, wird der kleine Bruder als inaktiv erachtet und beginnt die aktuelle Instanz ebenfalls die Beobachtung des kleinen Bruders ihres kleinen Bruders. Dies Anhäufung von Verantwortlichkeiten fährt bis zu einem vorbestimmten Maximum fort und stellt sicher, dass das Fehlverhalten einer Instanz nicht zu einem Versäumnis des Fehlers ihres kleinen Bruders führt. Wenn der kleine Bruder erneut beginnt, seinen Heartbeat zu erhöhen, werden sämtliche zusätzliche Verantwortlichkeiten fallen gelassen.
Wird eine Mitgliedsinstanz als tot oder nicht von Belang beurteilt, und wenn sie das APMP-Computersystem nicht von ihrer Absicht unterrichtet hat, abzuschalten oder abzustürzen, wird die Instanz aus dem APMP-System entfernt. Dies kann beispielsweise dadurch geschehen, dass das "Fehlerprüf"-Bit in der Instanz-Primitiv-Interrupt-Maske eingestellt wird und ein IP-Interrupt zu sämtlichen CPUs der Instanz gesendet wird. Als Regel kann auf gemeinsam genutzten Speicher lediglich unter der Hardwarepriorität des IP-Interrupts zugegriffen werden. Dadurch ist sichergestellt, dass, wenn die CPUs in der Instanz versuchen sollten, eine Ausführung bei einer Priorität unter jener des IP-Interrupts auszuführen, der IP-Interrupt zuerst auftreten wird und somit die CPU das "Fehlerprüf"-Bit erkennen wird, bevor beliebige Threads einer geringeren Priorität eine Ausführung durchführen können. Dadurch ist sichergestellt, dass die Betriebssystem-Instanz abstürzen wird und keine gemeinsam genutzten Ressourcen, wie etwa Speicher, antasten wird, die für andere Zwecke erneut zugeordnet wurden, als die Instanzen als tot beurteilt wurden. Als zusätzlicher oder alternativer Mechanismus kann ein Konsolen-Rückruf (sofern vorhanden) aufgerufen werden, um die Instanz zu entfernen. Wann immer darüber hinaus gemäß einer bevorzugten Ausführungsform eine Instanz verschwindet oder aus dem APMP-Computersystem ohne Warnung fortfällt, führen die verbleibenden Instanzen gewisse Zustandsprüfungen durch um zu bestimmen, ob sie fortfahren können. Diese Prüfungen beinhalten das Ve rifizieren, ob weiterhin auf sämtliche Seiten in der APMP-Datenbank zugegriffen werden kann, d. h. ob es keinen Speicherfehler gab.
Zuweisung von Ressourcen nach der Teilnahme
Eine CPU kann höchstens eine Besitzerpartition zu einem gegebenen Zeitpunkt während der Startzeit eines APMP-Systems haben. Die Widerspiegelung dieser Zugehörigkeit und der Einheit, die für deren Steuerung verantwortlich ist, können sich infolge von Konfigurations- und Zustandsübergängen denen die Ressource an sich ausgesetzt ist, der Partition, in der sie sich befindet, und der Instanz, die in dieser Partition läuft, ändern.
Die CPU-Zugehörgkeit wird auf vielfältige Art in einer Reihe von Strukturen angezeigt, die von der Einheit vorgegeben werden, die die Ressource zu diesem Zeitpunkt verwaltet. Im grundlegenden Fall kann sich die CPU in einem nicht zugewiesenen Zustand befinden und für sämtliche Partitionen verfügbar sein, die sich im selben gemeinsam nutzenden Satz befinden, wie die CPU. Schließlich wird die CPU einer speziellen Partition zugewiesen, die eine Betriebssystem-Instanz betreiben kann oder nicht. In jedem Fall spiegelt die Partition ihre Zugehörigkeit für alle weiteren Partitionen durch den Konfigurationsbaum-Aufbau und für alle Betriebssystem-Instanzen, die in dieser Partition laufen können, durch das AVAILABLE-Bit im HWRPB-Je-CPU-Kennzeichenfeld wider.
Läuft auf der besitzenden Partition keine Betriebssysteminstanz, ist deren Konsole für die Antwort auf und das Initiieren von Übergangsereignissen an den Ressourcen innerhalb dieser verantwortlich. Die Konsole entscheidet, ob sich die Ressource in einem Zustand befindet, der es ihr gestattet, zu einer weiteren Partition zu migrieren oder in den nicht zugewiesenen Zustand zurückzukehren.
Gibt es jedoch eine Instanz, die derzeit auf der Partition läuft, gibt die Konsole die Verantwortlichkeit zur Initiierung von Ressourcen-Übergängen auf und ist dafür verantwortlich, die laufende Primärinstanz in Kenntnis zu setzen, wenn eine Konfigurationsänderung stattgefunden hat. Sie ist weiterhin der Vermittler des zugrun de liegenden Hardware-Übergangs, wobei jedoch die Steuerung der Ressourcen-Übergänge eine Ebene zur Betriebssystem-Instanz angehoben wird. Der Transfer der Verantwortlichkeit findet statt, wenn die primäre CPU ihre erste Anweisung außerhalb der Konsolenbetriebsart bei einem Systemstart ausführt.
Betriebssystem-Instanzen können die Zugehörigkeits-Zustandsinformationen auf eine beliebige Art und Weise beibehalten, die die effizienteste Nutzung der Informationen intern unterstützen. Es kann beispielsweise eine Hierarchie von Zustands-Bitvektoren verwendet werden, die die instanzspezifischen Informationen sowohl intern als auch global (anderen Mitgliedern, die eine APMP-Datenbank gemeinsam nutzen) widerspiegeln.
Die internen Darstellungen sind strikt der Verwendung der Instanz zugewiesen. Sie werden zum Startzeitpunkt aus dem zugrundeliegenden Konfigurationsbaum und den HWRPB-Informationen aufgebaut, jedoch als strikte Software-Konstrukte für die Lebensdauer der Betriebssystem-Instanz beibehalten. Sie repräsentieren die Software-Sicht der Partitionsressourcen, die für die Instanz verfügbar sind, und können – durch Software-Regelsätze – die Konfiguration weiter auf einen Teilsatz dessen beschränken, was durch die physikalischen Konstrukte angezeigt ist. Trotzdem sind sämtliche Ressourcen in der Partition der Instanz zugehörig und werden von dieser – mit Hilfe des Konsolenmechanismus zur Anweisung von Zustandsübergängen – verwaltet, bis dieser Betriebssystemaufruf nicht länger eine durchführbare Einheit ist. Dieser Zustand wird angezeigt, indem die primäre CPU noch einmal zurück in die Konsolenbetriebsart angehalten wird, wobei es keine Möglichkeit gibt, ohne einen Neustart zurückzukehren.
Die Zugehörigkeit von CPU-Ressourcen erstreckt sich niemals über die Instanz hinaus. Die Zustandsinformationen jeder einzelnen Instanz werden in einer APMP-Datenbank zu Nur-Lese-Entscheidungs-Findungs-Zwecken dupliziert, wobei jedoch keine andere Instanz ein Zustandsübergangsereignis für die Ressource einer weiteren CPU erzwingen kann. Jede Instanz ist für das Verstehen und die Steuerung ihres eigenen Ressourcensatzes verantwortlich; sie kann externe Anfragen nach ihren Ressourcen empfangen, kann jedoch die Entscheidung treffen, um es den Ressourcen zu gestatten, übertragen zu werden.
Wird jede dieser CPUs betriebsbereit, stellt sie ihr AVAILABLE-Bit in den Je-CPU-Kennzeichen nicht ein. Ist das AVAILABLE-Bit nicht eingestellt, wird keine Instanz versuchen zu starten, oder erwarten, dass die CPU an einem SMP-Vorgang teilnimmt. Anstelle dessen pollt die CPU in der Konsolenbetriebsart das Besitzerfeld im Konfigurationsbaum, der darauf wartet, dass eine gültige Partition zugewiesen wird. Sobald eine gültige Partition als der Besitzer durch die primäre Konsole zugewiesen ist, beginnt die CPU den Betrieb in dieser Partition.
Während der Laufzeit spiegelt das current_owner-Feld die Partition wider, in der eine CPU die Ausführung durchführt. Das AVAILABLE-Bit im Je-CPU-Kennzeichenfeld im HWRPB bleibt der ultimative Indikator dafür, ob eine CPU derzeit verfügbar oder ausführend für einen SMP-Vorgang mit einer Betriebssystem-Instanz ist, und hat dieselbe Bedeutung, wie bei herkömmlichen SMP-Systemen.
Es wird darauf hingewiesen, dass eine Instanz nicht Mitglied eines gemeinsam nutzenden Satzes sein muss, um an zahlreichen der Neukonfigurationsmerkmale eines AMP-Computersystems teilzunehmen. Eine Instanz kann ihre Ressourcen zu einer weiteren Instanz im APMP-System übertragen, so dass eine Instanz, die kein Teil eines gemeinsam nutzenden Satzes ist, eine Ressource zu einer Instanz übertragen kann, die Teil des gemeinsam nutzenden Satzes ist. In ähnlicher Weise kann die Instanz, die nicht Teil des gemeinsam nutzenden Satzes ist, die Ressource von einer Instanz empfangen, die Teil des gemeinsam nutzenden Satzes ist.
Gemeinsam genutzter Speicher
Durch die Softwarekonfiguration, die im Konsolen-Konfigurationsbaum aufgezeichnet ist, wird ein Teil des Speichers als unter allen Instanzen in einer Gemeinschaft gemeinsam genutzt gekennzeichnet. Ein Teil des Speichers ist als privat für eine Partition markiert, die eine Instanz eines Betriebssystems ablaufen lassen kann. Der gesamte restliche Speicher ist als nicht zugehörig gekennzeich net. Da die Konfiguration durch die Software definiert ist, besteht die Möglichkeit, Partitionen und die relativen Größen von Partitionen dynamisch zu ändern.
Der gesamte Speicher innerhalb des physikalischen Hardware-Systems ist einem Besitzer-Feld innerhalb des Konfigurationsbaumes zugeordnet. Der Speicher kann einer Partition zugehörig sein, wobei in diesem Fall der Speicher als privater Speicher vom Betriebssystem oder der Konsolensoftware verwendet wird, die innerhalb der Partition läuft. Dieser wird als "privater" Speicher bezeichnet. Alternativ kann der Speicher einer Gemeinschaft zugehörig sein, wobei in diesem Fall der Speicher für sämtliche Instanzen innerhalb der Gemeinschaft gemeinsam genutzt wird und derartiger Speicher als "gemeinsam genutzter" Speicher bezeichnet wird. Der Speicher kann zudem so konfiguriert sein, dass er keiner Partition oder Gemeinschaft zugehörig ist. Ein derartiger "nicht zugehöriger" Speicher kann heruntergefahren oder ausgetauscht (out-swapped) werden, während der übrige Teil des Systems mit dem Betrieb fortfährt, wenn die Hardware ein derartiges "Hot Outswapping" zulässt.
Der Speicher kann innerhalb der Instanzen in einer Gemeinschaft durch die Verwendung von gemeinsam genutzten Speicherbereichen gemeinsam genutzt werden. Ein gemeinsam genutzter Speicherbereich kann von einer beliebigen Instanz erzeugt werden. Es wird ein Etikett festgelegt, um den Zugriff auf denselben Bereich durch mehrere Instanzen zu koordinieren. Eine virtuelle Größe wird ebenso festgelegt wie eine physikalische Größe. Die virtuelle Größe kann dieselbe Größe oder größer sein als die physikalische Größe. Der gemeinsam genutzte Speicher wird durch eine Ruckrufroutine initialisiert. Es wird eine Verriegelung während der Initialisierung gehalten, um andere Instanzen zu blockieren, auf den Bereich abzubilden, während der Bereich initialisiert wird. Sobald der gemeinsam genutzte Speicherbereich durch eine Instanz erzeugt ist, können andere Instanzen abgebildet und an den Bereich angefügt werden. Ein Null-Seiten-Tabelleneintrag wird verwendet, um Seiten zu kennzeichnen, die virtuell Teil des Bereiches sind, jedoch keinen physikalischen Speicher haben, der ihnen zugeordnet ist. Der Speicherbereichsdatenaufbau zeichnet auf, welche Instanzen an den Bereich angefügt wurden. Eine Instanz muss eine Rückrufroutine festlegen, wenn sie an einen gemeinsam genutzten Speicherbereich angefügt wird. Diese Routine wird aus meh reren Gründen aufgerufen: während der Initialisierung oder des Herunterfahrens des Systems, oder immer dann, wenn eine weitere Instanz an den Bereich angefügt oder von diesem getrennt wird, oder immer dann, wenn eine Instanz, die angefügt worden war, abgestürzt ist (in nicht ordnungsgemäßer Art getrennt wurde). In Abhängigkeit des Rückrufgrundes, beispielsweise während des Herunterfahrens, wird erwartet, dass die Rückrufroutine den Zugriff auf den gemeinsam genutzten Speicherbereich blockiert.
Eine Instanz kann es verlangen, dass mehr physikalischer Speicher einem Bereich hinzugefügt werden kann. Lediglich jene Instanz, die diese Anfrage zu beginn ausführt, bildet diese Seiten ab. Wenn eine weitere Instanz versucht, auf diese Seiten zuzugreifen, erlangt eine Zugriffsstörungs-Handhabungseinrichtung Steuerung (da diese Instanz über einen Null-Seiten-Tabelleneintrag (PTE) verfügt, der diesem Speicherbereich zugeordnet ist), wobei die Zugriffsstörungs-Handhabungseinrichtung den Abbildungsbereich mit beliebigen neuen Seiten aktualisiert. Wenn eine Instanz die Abbildung des Bereichs aufhebt, wird diese Trennung in der APMP-Datenbank aufgezeichnet. Wurden sämtliche Instanzen von einem Bereich gelöst, kann dieser gelöscht werden und können sämtliche Seiten für eine Seitenliste ohne gemeinsam genutzten Speicher freigegeben werden. Der gemeinsam genutzte Speicherbereichs-Datenaufbau zeichnet zudem auf, welche Instanzen einen bevorstehenden I/O auf eine beliebige Seite innerhalb des Bereiches haben. Die Betriebssystem-Instanzen zeichnen ihre individuellen Bezugszähler auf, so dass sie wissen, wann sie ihr I/O-Bit im Bereich einstellen und löschen sollen. Eine Instanz kann die Abbildung nicht aufheben und sich von einem gemeinsam genutzten Speicherbereich lösen, wenn sie einen ausstehenden I/O auf eine beliebige Seite innerhalb des Bereiches hat.
Eine API des gemeinsam genutzten Speichers ist ein Satz von Routinen, der von Benutzerbetriebsart-Applikationen aufgerufen werden kann, und bildet gemeinsam genutzten Speicher in den Applikations-Adressraum ab. Wird ein gemeinsam genutzter Speicherbereich erzeugt, wie es oben beschrieben ist, verfolgt die erzeugende Instanz, wie sich die Datenstrukturen des Betriebssystems auf den gemeinsam genutzten Speicherbereich beziehen. Hat die Instanz Datenstrukturen für den gemeinsam genutzten Speicherbereich erzeugt, wird die Instanz am Be reich angebracht. Wird die Abbildungs-API-Routine des gemeinsam genutzten Speichers aufgerufen, werden anschließend herkömmliche Betriebssystem-Mechanismen verwendet, um den Applikations-Adressraum auf den gemeinsam genutzten Speicherbereich abzubilden. Wenn die lokalen Betriebssystem-Datenstrukturen bereinigt werden, wird die Instanz vom Bereich getrennt. Ein globaler Abschnitt kann einem gemeinsam genutzten Speicherbereich eins zu eins zugeordnet werden.
Eine Instanz kann eine "Kontextvariable" festlegen, die einem Bereich zugeordnet werden soll. Wenn eine weitere Instanz versucht, sich an einen Bereich anzufügen, und nicht denselben Kontext festlegt, wird ein Fehler zurückgesendet. Diese Festlegung einer Kontextvariablen kann beispielsweise verwendet werden, um eine Versionsnummer der Applikation zuzuordnen. Darüber hinaus kann eine Instanz eine private Kontextvariable festlegen, die den privaten Daten der Instanz zugeordnet werden sollen, die für einen Bereich gespeichert sind. Wird eine Rückrufroutine aufgerufen, kann die Instanz zusätzliche Informationen über den Bereich sammeln, indem sie die private Kontextvariable bezieht. Der private Kontext kann beispielsweise verwendet werden, um eine Anschlussnummer zu speichern.
Gemeinsam genutzter Speicher kann von einer Betriebssysteminstanz für die Verwendung als privater Speicher der Instanz geborgt werden. Gemeinsam genutzter Speicher kann durch die Verwendung der API des gemeinsam genutzten Speichers geborgt werden. Gemeinsam genutzter Speicher kann erzeugt und anschließend lediglich von der lokalen Instanz verwendet werden. Dies Technik ist hilfreich, wenn nicht der gesamte Speicher, der als gemeinsam genutzt markiert ist, von den Gemeinschaftsmitglieder-Instanzen verwendet wird. Der zusätzliche gemeinsam genutzte Speicher kann eine zusammengefasste Quelle von freiem Speicher sein. Mit anderen Worten kann gemeinsam genutzter Speicher durch die Erzeugung eines gemeinsam genutzten Speicherbereiches geborgt werden. Die Seiten im gemeinsam genutzten Speicherbereich können vom lokalen Betriebssystem für unterschiedliche Zwecke verwendet werden.
Privater Speicher kann so konfiguriert sein, dass er der Instanz zugehörig ist, deren CPU(s) den schnellsten Zugriff auf den Speicher hat (haben). Ein nicht ein heitlicher Speicherzugriff wird im Aufbau des gemeinsam genutzten Speichers dadurch aufgefangen, dass interne Datenstrukturen für den gemeinsam genutzten Speicher in Gruppen gemäß den Hardware-Eigenschaften des Speichers organisiert werden. Diese internen Datenstrukturen werden Gemeineigenschafts-Partitionen genannt. Die API des gemeinsam genutzten Speichers gestattet es, dass Speichereigenschaften durch den Anrufer festgelegt werden können. Diese Charakteristika können als Eigenschaften nicht einheitlichen Speicherzugriffs, wie etwa "nah" und "fern" bezeichnet werden.
Die PFN-Datenbank nimmt privaten Speicher sowie gemeinsam genutzten Speicher und neu konfigurierten Speicher mit Hilfe einer großen Anordnung von Seitenrahmenzahl-(PFN-)Einträgen auf. Es gibt keinen physikalischen Speicher hinter einer virtuellen Anordnung, die Seiten beschreibt, die für eine weitere Instanz privat sind, noch Speicherorten entspricht, die von Speicherbaugruppen unterstützt werden, die dem System fehlen, noch physikalischen Speicheradresslöchern entsprechen. Die. Anordnung der PFN-Datenbank legt eine spezielle Granularität des physikalischen Speichers nahe. Das heißt, um eine ganzzahlige Zahl von physikalischen Seiten für die PFN-Datenbank zuzuweisen und zu verbrauchen, die sich innerhalb jedes Speicherblocks befinden soll, sollte der physikalische Speicher eine Granularität haben, die im folgenden beschrieben ist. Die Granularität des physikalischen Speichers wird als die geringste Größe von Speicher gewählt, der eine ganzzahlige Zahl von Seiten und eine integrale Zahl von PFN-Datenbankeinträgen enthält. Dies ist durch das kleinste gemeinsame Vielfache der Speicherseitengröße und der Seitenrahmen-Datenbankeinträge in Quad-Worten gegeben.
Wie es oben beschrieben wurde, schreitet eine Erzeugungs-Instanz, insbesondere das Initialisierungsprogramm des APMP-Computersystems, den Konfigurationsbaum ab und erzeugt Verwaltungsstrukturen für ihren zugehörigen gemeinsam genutzten Speicher der Gemeinschaft. Im allgemeinen stellen vier hierarchische Zugriffsarten die Speicherzugriffssteuerung bereit. Die Zugriffsknoten sind in der Reihenfolge der stärksten bis geringsten Privilegierung: Kern, ausführend, Verwalter und Benutzer. Darüber hinaus wird der Speicherschutz auf einer individuellen Seitenebene festgelegt, wobei für jede der vier Zugriffsarten auf eine Seite nicht zugegriffen werden kann, diese nur lesbar ist oder von dieser gelesen oder auf diese geschrieben wird. Seiten, auf die zugegriffen werden kann, können darauf beschränkt sein, dass sie lediglich Daten- oder Anweisungszugriff haben. Eine Speicherverwaltungssoftware wartet Tabellen aus Abbildungsinformationen (Seitentabellen), die verfolgen, wo sich jede virtuelle Seite im physikalischen Speicher befindet. Ein Vorgang durch eine Speicherverwaltungseinheit verwendet diese Abbildungsinformationen, wenn er virtuelle Adressen in physikalische Adressen übersetzt. Der virtuelle Adressenraum wird in Einheiten von Umplatzierungs-, Gemeinsamnutzungs- und Schutzseiten zerlegt, die als Seiten bezeichnet werden. Eine Betriebssystem-Instanz steuert die Tabellen für virtuelle auf physikalische Abbildung und sichert inaktive Teile des virtuellen Speicheradressraumes auf externen Speichermedien.
Die Speicherverwaltung verwendet beispielhaft einen Quad-Wort-Tabelleneintrag, um virtuelle Adressen in physikalische Adressen zu übersetzen. Jeder Seitentabelleneintrag (PTE) enthält eine Seitenrahmenzahl (PFN), die auf eine Seitengrenze verweist, und kann mit einem Byte-in-Seite-Indikator einer virtuellen Adresse verknüpft sein, die zu einer physikalischen Adresse führt.
Die Übersetzung der physikalischen Adresse erfolgt zu Zugriff auf Einträge in einem Mehrfachebenen-Seitenaufbau. Ein Seitentabelllen-Basisregister (PTBR) enthält die physikalische PFN der Seitentabelle der höchsten Ebene. Bits der virtuellen Adresse werden verwendet, um in die Seitetabellen höherer Ebene zu verweisen, um die physikalischen PFNs der Basisseitentabellen niedrigerer Ebene zu erhalten und um auf der niedrigsten Ebene die physikalische PFN der Seite zu erhalten, auf die sich bezogen wird. Diese PFN ist mit dem Byte-in-Seite-Indikator der virtuellen Adresse verknüpft, um die physikalische Adresse des Ortes zu beziehen, auf den zugegriffen wird.
Wie es oben erläutert wurde, kann eine Instanz entscheiden, am Betrieb einer Gemeinschaft zu einer beliebeigen Zeit teilzunehmen, die nicht unbedingt die Systemstartzeit ist. Entscheidet eine Instanz, dem APMP-System beizutreten, ruft sie eine Routine DB_MAP_initial auf, die die APMP-Daten-Basisseiten vom Konfi gurationsbaum-Gemeinschaftsknoten bezieht und das anfängliche Stück der APMP-Datenbank abbildet. Enthält der Konfigurationsbaum noch keine APMP-Datenbankseiten, wählt die Instanz Seiten gemeinsam genutzten Speichers, die für die APMP-Datenbank verwendet werden sollen. Die Instanz ruft den Konsolencode auf, in den Konfigurationsbaum in asynchroner Weise zu schreiben. Nach dem Abbilden des anfänglichen Stückes der APMP-Datenbank, wird, wie es oben beschrieben ist, bestimmt, ob die Instanz das APMP-System erzeugt oder diesem beitritt.
Ist die Instanz der Erzeuger des APMP-Systems, ruft die Instanz eine Routine DB_allocate auf, um die Seiten für die APMP-Datenbank zuzuteilen und die Abbildungsinformationen innerhalb einer MMAP-Datenstruktur zu initialisieren. Die MMAP-Datenstruktur, die im folgenden detaillierter beschrieben wird, wird verwendet, um das Abbilden gemeinsam genutzten Speichers zu beschreiben. Die Routine DB_allocate löst nicht die Abbildung des anfänglichen Stückes der APMP-Datenbank. Ist die Instanz ein Verbindungsstück eines APMP-Systems, ruft die Instanz eine Routine DB_Map_continue auf, um die APMP-Datenbank abzubilden. Die Routine DB_Map_continue löst nicht die Abbildung des anfänglichen Stückes der APMP-Datenbank. Sobald die APMP-Datenbank abgebildet ist und der Code der Verbindungsinstanz umgeschaltet hat, um auf eine neu abgebildete APMP-Datenbank anstelle der anfänglichen APMP-Datenbank Bezug zu nehmen, wird die Abbildung der anfänglichen APMP-Datenbank aufgehoben, indem eine Routine DB_unmap aufgerufen wird. Diese Routine kann zudem aufgerufen werden, um die Abbildung der APMP-Datenbank aufzuheben, wenn eine Instanz das APMP-System verlässt.
Die APMP-Datenbank muss sich nicht am selben virtuellen Ort für sämtliche Instanzen befinden, da diese verhindern würde, dass Instanzen am APMP-System teilnehmen, wenn ein gegebener Bereich von virtuellen Adressen nicht verfügbar wäre. Dies Flexibilität lässt es zu, dass unterschiedliche Betriebssysteme, die unterschiedliche virtuelle Adressraumanordnungen haben, auf einfache Art und Weise im neuen APMP-System koexistieren.
Die DB_Map_initial-Routine bildet das anfängliche Stück der APMP-Datenbank ab, akzeptiert die Länge der anfänglichen APMP-Datenbank und gibt die virtuelle Adresse der anfänglichen APMP-Datenbank zurück. Zusätzlich prüft DB_Map_initial die abgebildeten Seiten um sicherzustellen, dass die Seiten aus einem gemeinsam genutzten Speicher stammen, und um beliebige fehlerhafte Seiten zu markieren.
Die DB_allocate-Routine akzeptiert die volle Adresse der anfänglichen APMP-Datenbank, die Länge der anfänglichen APMP-Datenbank und die Länge der gesamten APMP-Datenbank. Die Routine gibt die virtuelle Adresse der gesamten APMP-Datenbank zurück. Die Routine weist ausreichenden Instanzen-Adressraum zu, um die gesamte APMP-Datenbank abzubilden, und bildet das anfängliche Stück der APMP-Datenbank zu Beginn dieses Raumes erneut ab. Zusätzliche APMP-Datenbankseiten werden vom gemeinsam genutzten Speicher je nach Erfordernis abgebildet. Diese Seiten können überprüft werden, und wenn eine fehlerhafte Seite angetroffen wird, wird sie als benutzt markiert. Der Rest der APMP-Datenbankseiten wird in die geeigneten Seitentabelleneinträge abgebildet. Aneinander grenzende Seiten werden für die APMP-Datenbank-PFN-Liste zugeteilt. Die APMP-Datenbank-PFNs werden in den PFN-Listensseiten gespeichert, wobei unbenutzte Einträge genullt werden. Sind genügend aufeinander folgende Seiten für die gesamte APMP-Datenbank verfügbar, werden keine PFN-Listenseiten verwendet. Gemeinsam genutzte Seiten werden direkt aus dem Konfigurationsbaum zugeordnet und von der Seite direkt nach den anfänglichen APMP-Datenbankseiten genommen.
Die DB_Map_continue-Routine bildet die gesamte APMP-Datenbank ab, wenn ein Anrufer nicht der Erzeuger des APMP-Systems ist. Die Routine akzeptiert die virtuelle Adresse der anfänglichen APMP-Datenbank und die Länge der anfänglichen APMP-Datenbank. Die Routine gibt die virtuelle Startadresse der gesamten APMP-Datenbank und die Länge der gesamten APMP-Datenbank zurück.
Jede Betriebssystem-Instanz enthält Speicherkonfigurations-Informationsfunktionen, die sich auf die Speicheraspekte des Konfigurationsbaumes konzentrieren. Eine MEM_CONFIG_INFO-Routine gibt die Basisspeicher- Konfigurationsinformationen zurück indem sie die Konfigurationsbaumfelder MAX_DESC und MAX_FRAGMENTS liest und die maximale Anzahl von Speicher-Deskriptorknoten und die maximale Anzahl von Speicherfragmenten pro Deskriptorknoten zurückgibt. Eine MEM_CONFIG_PFN-Routine bestimmt, welche Partition eine gegebene PFN enthält. Diese Routine akzeptiert eine Seitenrahmenzahl und gibt eine Kennzeichnung zurück, von welchem Typ die Seite ist, d. h. ob die Seite eine gemeinsam genutzte oder private Seite für eine spezielle Partition, eine Eingangs-/Ausgangs-(I/O-)Seite oder ein nicht zugehöriger Speicher ist. Ist die Seite privat oder wird sie von Zugriffs-I/O-Seiten verwendet, gibt die Routine eine Kennzeichnung zurück, welche Partition diese PFN enthält, und wenn die Seite gemeinsam genutzt ist, welche Gemeinschaft die PFN besitzt. Die SHMEM_CONFIG_DESC-Routine gibt Informationen gemeinsam genutzten Speichers über einen Speicherdeskriptor im Konfigurationsbaum zurück. Sobald kein Speicherdeskriptor-Knoten gefunden wird, sucht die Routine die Speicherfragmente nach jenen Fragmenten ab, die als gemeinsam genutzt markiert sind und fügt einen Rückgabepuffer mit der PFN und einer Seitenzahl für jedes Fragment ein. Gibt es keine Speicherfragmente, die als gemeinsam genutzt markiert sind, wird eine Fragmentzahl auf Null eingestellt.
Die SHMEM_CONFIG_ALL-Routine gibt Informationen über sämtliche Speicherdeskriptor-Knoten zurück, die gemeinsam genutzten Speicher beinhalten. Die Routine ruft SHMEM_CONFIG_DESC in einer Schleife auf, um sämtliche gemeinsam genutzte Speicher-Seitenbereiche zu beziehen. Eingabeargumente beinhalten die Maximalzahl von Speicher-Deskriptorknoten und die Maximalzahl von Speicherfragmenten je Deskriptorknoten. Die Routine gibt die Gesamtzahl von gemeinsam genutzten Speicherfragmenten von einer Anordnung von Strukturen zurück, die die Bereiche gemeinsam genutzten Speichers beschreiben.
Eine Routine SHMEM_CONFIG_APMP stellt den APMP-PFN-Bereich im Konfigurationsbaum ein. Wurde der APMP-PFN-Bereich bereits eingerichtet, gibt sie die Informationen zurück. Die Routine gibt die erste für die APMP-Datenbank zu verwendende PFN und die Zahl von APMP-Seiten zurück. Diese Routine liest einen Wert innerhalb eines Gemeinschaftsknotens und bezieht, sofern der Wert Null ist, den ersten zusammenhängenden Bereich gemeinsam genutzten Speichers, acht Megabyte bei der beispielhaften Ausführungsform, durch Aufrufen der SHMEM_CONFIG_DESC-Routine. Anschließend ruft sie die Konsolen-Ausfertigungsroutine auf, um diesen Bereich im Gemeinschaftsknoten einzustellen. Gab es Eile, den APMP-Seitenbereich einzustellen, wird der Bereich, der im Konfigurationsbaum eingestellt ist, gelesen und an den Anrufer zurückgegeben.
Eine Datenstruktur zur Verwaltung gemeinsam genutzten Speichers in der APMP-Datenbank SHMEM enthält die Versionsnummer, die Größe des fixierten Teils der SHMEM-Struktur, Kennzeichen, die anzeigen, ob der gemeinsam genutzte Speicher gültig ist, ob sich die Initialisierung im Fortschritt befindet, ob Fehlerbeseitigungs-Strukturformate verwendet werden, ob sämtliche Seiten innerhalb sämtlicher Gemeineigenschafts-Partitionen gemeinsam genutzten Speichers geprüft wurden, und die Maximalzahl von Gemeineigenschafts-Partitionen gemeinsam genutzten Speichers. Zusätzlich enthält die Datenstruktur die Gesamtzahl gültiger Gemeineigenschafts-Partitionen gemeinsam genutzten Speichers, die Größe einer Gemeineigenschafts-Partitionsstruktur gemeinsam genutzten Speichers, Offsets vom Beginn der Datenstruktur gemeinsam genutzten Speichers zur Gemeineigenschafts-Partitionsanordnung gemeinsam genutzten Speichers, einen Offset vom Beginn der Datenstruktur gemeinsam genutzten Speichers zur Verriegelungsstruktur gemeinsam genutzten Speichers, ein Verriegelungs-Handle gemeinsam genutzten Speichers und die Maximalzahl von Bereichen gemeinsam genutzten Speichers innerhalb des APMP-Systems. Die Datenstruktur enthält zudem die Gesamtzahl gültiger Bereiche gemeinsam genutzten Speichers und einen Offset vom Beginn der Datenstruktur gemeinsam genutzten Speichers zur Etikettbereichsstruktur gemeinsam genutzten Speichers. Die Größe einer Bereichsstruktur gemeinsam genutzten Speichers und der Offset vom Beginn der Verwaltungsdatenstruktur gemeinsam genutzten Speichers zur Bereichsanordnung gemeinsam genutzten Speichers ist ebenfalls enthalten.
Instanz-Privatspeicher-Datenzellen enthalten Informationen über den Verwaltungsbereich gemeinsam genutzten Speichers in der APMP-Datenbank. Diese Informationen beinhalten einen Verweis zum Beginn der Datenstruktur gemeinsam genutzten Speichers und dieselben Deskriptoren, wie sie im Bezug auf die Datenstruktur gemeinsam genutzten Speichers beschrieben wurden: die Maxi malzahl von Gemeineigenschafts-Partitionen gemeinsam genutzten Speichers, die Maximalzahl von Speicherfragmenten in jeder Gemeineigenschafts-Partition gemeinsam genutzten Speichers, die Größe einer Gemeineigenschafts-Partitionsstruktur gemeinsam genutzten Speichers, einen Verweis zu einer Gemeineigenschafts-Partitionsanordnung gemeinsam genutzten Speichers innerhalb der APMP-Datenbank, einen Verweis auf eine Liste gemeinsam genutzten Speichers und einen Verweis zu einer Etikettbereichsanordnung gemeinsam genutzten Speichers innerhalb der APMP-Datenbank. Darüber hinaus sind die Maximalzahl von Bereichen gemeinsam genutzten Speichers, die Größe einer Bereichsstruktur gemeinsam genutzten Speichers, ein Verweis auf eine Bereichsanordnung gemeinsam genutzten Speichers innerhalb der APMP-Datenbank und ein Verweis auf die Deskriptoranordnung gemeinsam genutzten Speichers im privaten Speicher enthalten.
Wenn eine Gemeineigenschafts-Partitions-(CPP-)Konfigurationsbereich gemeinsam genutzten Speichers initialisiert wird, werden die APMP-Datenbankseiten ausgeschlossen. Gemeineigenschafts-Partitionen gemeinsam genutzten Speichers unterstützen das Hot-Swapping und den nicht einheitlichen Speicherzugriff durch Partitionieren gemeinsam genutzten Speichers in Partitionen die gemeinsame Eigenschaften haben. Kennzeichen und Routinen werden verwendet, um beispielsweise neben dem Bereich und dem Ort von Speicherseiten innerhalb der Einheit zu kennzeichnen, in welcher Einheit nicht einheitlichen Speicherzugriffs sich eine CPP befindet oder in welcher Einheit, die ein Hot-Swapping unterstützt, sich die CPP befindet. Jede Instanz, die ein Mitglied eines APMP-Systems ist, hält Daten innerhalb seines eigenen privaten Speichers, die jede CPP gemeinsam genutzten Speichers betreffen, mit der sie verbunden ist. Ein Verriegelungsaufbau wird verwendet, um den Zugriff auf die Gemeineigenschafts-Partitions-Datenstruktur gemeinsam genutzten Speichers zu synchronisieren. Die Verriegelung wird gehalten, wenn sich eine Partition mit der CPP gemeinsam genutzten Speichers verbindet, wenn sich eine Partition von einer CPP gemeinsam genutzten Speichers trennt, wenn Seiten von der CPP gemeinsam genutzten Speichers zugeteilt werden, oder wenn die Zuweisung von Seiten zur CPP gemeinsam genutzten Speichers aufgehoben wird. Jede CPP gemeinsam genutzten Speichers hat eine freie Seitenliste, eine Liste fehlerhafter Seiten und eine Liste nicht geprüfter Seiten. Seiten können aus den Listen freier Seiten und nicht geprüfter Seiten zugeteilt werden und es kann deren Zuteilung in die Liste freier Seiten und die Liste fehlerhafter Seiten aufgehoben werden. Die Seitenlistenverknüpfungen einer CPP gemeinsam genutzten Speichers werden innerhalb der PFN-Datenbankeinträge für die Seiten beibehalten.
Die Verriegelung des gemeinsam genutzten Speichers wird verwendet, um die SHM_TAG-Anordnung und eine zugehörige Liste von gültigen SHM_REG-Strukturen zu synchronisieren und um den Zugriff auf die Liste zu synchronisieren, die frei von SHM_REG-Strukturen ist. Die SHMEM-Verriegelung muss gehalten werden, während die SHM_TAG-Anordnung gelesen oder geschrieben wird, während eine Liste von gültigen SHM_REG-Strukturen gehandhabt wird, oder während eine SHM_REG-freie Liste gehandhabt wird. Die Verriegelungen gemeinsam genutzten Speichers sind wie folgt abgestuft: die Verriegelung höchster Ordnung ist eine IPL-8-SMP-Spin-Verriegelung, gefolgt von der SHM_CPP-Verriegelung, der SHM_REG-Verriegelung und schließlich der SHMEM-Verriegelung. Während beispielsweise die SHMEM-Verrriegelung gehalten wird, kann man eine SHM_REG-Verriegelung, eine SHM_CPP-Verriegelung und/oder eine SMP-Spin-Verriegelung in dieser Reihenfolge erhalten. Verwaltungsfunktionen gemeinsam genutzten Speichers können von einer Kernbetriebsart abgerufen werden, um Informationen über gemeinsam genutzten Speicher zu erhalten. Die SHMEM-Verriegelung hat eine Abstufung gegenüber anderen Verriegelungen, die derart beschaffen ist, dass keine Blockierungen auftreten.
B. MIGRIEREN VON RESSOURCEN IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (9–10E)
Gemäß einem Aspekt der Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend in einem einzigen Multiprozessor-Computer ausgeführt, wobei eine einzige physikalische Maschine durch Software in mehrere Partitionen unterteilt ist, die jeweils die Fähigkeit haben, eine spezielle Kopie oder eine Instanz eines Betriebssystems laufen zu lassen. Jede einzelne Instanz verfügt über die Ressourcen, die sie benötigt um unabhängig ausgeführt zu werden, wo bei jedoch Instanzen zusammenwirken, um Ressourcen von einer Partition zu einer weiteren zu migrieren. Gemäß den Prinzipien dieses Aspektes der Erfindung kann die Migration unter Steuerung der Betriebssysteminstanzen "fliegend" ohne Eingreifen des Systemadministrators initiiert und ausgeführt werden. Alternativ kann ein Systemadministrator das System neu konfigurieren.
Gemäß einer Ausführungsform wird die Ressourcenmigration in einem "Verschiebe"-Modell ausgeführt, in dem Ressourcen von einer besitzenden Partition gesteuert und von dieser Partition freigegeben werden müssen, bevor sie zu einer weiteren Partition migriert werden können. In Übereinstimmung mit diesem Modell fordert zuerst eine erste Betriebssystem-Instanz, die eine Ressource benötigt, die Ressource von einer zweiten Instanz an. In Erwiderung auf diese Anfrage bestimmt die zweite Instanz, ob sie auf die Ressource verzichten kann, und beginnt, wenn dies der Fall ist, die Ressource in einen Leerlaufzustand zu bringen. Zudem kann in Übereinstimmung mit dem "Verschiebe"-Modell die Anforderung für die Ressourcenmigration von einer Bedienperson initiiert werden, die ein Programm auf der zweiten Instanz ablaufen lässt, oder von einer Richtlinien-Verwaltungssoftware, die die Anfrage initiiert.
Laufzeit-Migration von Ressourcen
Nachdem ein APMP-System läuft, können sich Ressourcen, die zu Beginn einer Partition zugeordnet wurden, zu einer weiteren Partition bewegen oder zu dieser migrieren. Diese Migration kann unter Steuerung eines Systemadministrators stattfinden, oder kann durch eine Betriebs-Instanz ohne Eingreifen des Systemadministrators initiiert werden. Die Migration wird erreicht, indem die besitzende Betriebssystem-Instanz veranlasst wird, die Verwendung einer Ressource zu stoppen, oder durch ein Konsolen-Programm, das eine Tätigkeit ausführt, um die Verwendung einer Ressource zu stoppen. Der Konfigurationsbaum wird anschließend verändert, um die Zugehörigkeit der Ressource auf eine andere Betriebssystem-Instanz zu übertragen. Die neue Betriebssystem-Instanz beginnt anschließend, die Ressource zu verwenden. Die Tätigkeit, die erforderlich ist, eine Betriebssysteminstanz zu veranlassen, die Verwendung einer Ressource zu stoppen, ist betriebssystemspezifisch.
Im allgemeinen kann eine beliebige Ressource migrieren, solange die Migration nicht durch zusätzliche Systemeinschränkungen verhindert wird. Beispielsweise kann eine beliebige CPU im APMP-System von einer ersten Partition zu einer zweiten Partition bewegt werden, vorausgesetzt, sie ist momentan keine primäre CPU in der ersten Partition und ist nicht durch Betriebssystemeinschränkungen, wie etwa eine verteilte Interrupt-Handhabung, gebunden. Die Richtlinie, wann und wo eine CPU migrieren kann, liegt strikt beim Code des Betriebssystems, den die CPU ausführt.
Der Speicher kann zudem von einer ersten Partition zu einer zweiten Partition migriert werden. Ist der Speicher ausschließlich der ersten Partition zugehörig, kann er unverzüglich migriert werden. Wird der Speicher zwischen zwei Partitionen gemeinsam genutzt, können einige zusätzliche Schritte notwendig sein um sicherzustellen, dass der Speicher vor der Migration von sämtlichen Partitionen entladen wird.
Vorzugsweise wird die Migration ausgeführt, ohne das gesamte APMP-System neuzustarten, wenngleich die Migration bestimmter Ressourcen einen Neustart einer oder beider Partitionen, die an der Ressourcen-Migration teilnehmen, in Abhängigkeit der Art der Änderung und der Betriebssystemeigenschaften erfordert. Die Migration eines Eingangs-/Ausgangs-Prozessors von einer Partition zu einer weiteren Partition kann es beispielsweise erfordern, dass beide Partitionen neustarten. Die Änderung der Speicherzuordnung einer oder mehrerer Speicherfragmente kann jedoch vom Code des Betriebssystems ohne das Erfordernis eines Neustartes gehandhabt werden.
Der Migrationsvorgang erfolgt unter einem "Verschiebe"-Modell dahingehend, dass der ursprünglich Besitzer der Ressource zunächst die Ressource freigeben muss, bevor der neue Besitzer mit der Verwendung der Ressource beginnen kann. Die grundlegenden Schritte bei einer Ausführungsform dieses Verschiebe- Migrationsvorgangs sind im Flussdiagramm in 9 und schematisch in 10A–10E dargestellt.
In 9 beginnt ein Ressourcen-Migrationsvorgang in Schritt 900 und schreitet zu Schritt 902 fort, bei dem eine Betriebssystem-Instanz (wie etwa die Betriebsinstanz 2), die eine Ressource benötigt, die Verwendung einer Ressource von einem weiteren Betriebssystem anfordert, das beispielsweise in der Systeminstanz 1 arbeitet. Die Kommunikation zwischen den Prozessoren kann mit einer Reihe von herkömmlichen und hinlänglich bekannten Mechanismen, wie etwa Zwischenprozessor-Interrupts, gemeinsamen Speicher oder beiden Mechanismen ausgeführt werden. Dieser Betriebsschritt ist ebenfalls in 10A gezeigt. 10A zeigt ein beispielhaftes System, das aus zwei Partitionen besteht: Partition 1 (1000) und Partition 2 (1002). Jede Partition 1000 und 1002 enthält ein Konsolen-Programm, das schematisch als Kasten 1006 bzw. 1016 dargestellt ist. Jede Partition 1000 und 1002 enthält zudem eine Betriebssysteminstanz, die in der Betriebssystem-Instanz 1 (1008) und der Betriebssystem-Instanz 2 (1018) dargestellt ist. Die Partition 1 (1000) enthält darüber hinaus eine Ressource 1010, die von einer Betriebssystem-Instanz 1 (1008) verwendet wird, wie es schematisch mit dem Pfeil 1011 gekennzeichnet ist. Beim ersten Schritt des Migrationsvorgangs, macht die Betriebssystem-Instanz 2 (1018) eine Anfrage, die schematisch mit dem Pfeil 1014 gekennzeichnet ist, an die Betriebssystem-Instanz 1 (1008), die Ressource 1010 zu verwenden.
Gemäß dem Verschiebemodell, das bei der vorliegenden Erfindung verwendet wird, muss die Betriebssystem-Instanz 1 (1008) dem Transfer der angeforderten Ressource 1010 zur Betriebssystem-Instanz 2 (1018) zustimmen. Stimmt die Betriebssystem-Instanz 1 (1008) zu, legt sie die Ressource 1010 still, wie es in Schritt 904 gezeigt ist. Der nächste Schritt des Vorgangs ist ebenfalls schematisch in 10B dargestellt, bei dem die Elemente, die zu 10A gleich sind, mit denselben Bezugszeichen gekennzeichnet sind. Beispielsweise ist die Partition 1 mit 1000 in 10A und 10B gekennzeichnet. Wenn, wie es in 10B gezeigt ist, die Betriebssystem-Instanz 1 (1008) zustimmt, die Ressource zu migrieren, legt die Betriebssystem-Instanz 1 1008 still oder stoppt ihre Verwendung von Ressource 1010, wie es schematisch mit dem gepunkteten Pfeil 1020 gezeigt ist.
Als nächstes informiert die Betriebssystem-Instanz 1 (1008) die Konsole 1 (1006) über die beabsichtigte Änderung der Zugehörigkeit der Ressource, wie es in Schritt 906 gezeigt ist. Dieser Schritt im Migrationsvorgang ist in 10C gezeigt. Bei diesem Schritt informiert die Betriebssystem-Instanz 1 (1008) die Konsole 1, dass ein Transfer der Zugehörigkeit erforderlich ist, wie es schematisch mit dem Pfeil 1022 gezeigt ist. Insbesondere informiert die Betriebssystem-Instanz 1 (1008) die Konsole 1 (1006), den Besitzer und die current_owner-Felder für die Ressource 1010 im Konfigurationsbaum 1012 zu ändern, wie es im folgenden beschrieben ist.
Als nächstes ändert in Schritt 908 die Konsole 1 (1006) den Konfigurationsbaum 1012, um den neuen Besitzer der Ressource zu kennzeichnen. Dieser Schritt ist schematisch in 10D gezeigt, bei dem die Konsole 1 (1006) den Konfigurationsbaum 1012 abändert, wie es schematisch mit dem Pfeil 1026 gezeigt ist. Diese Abänderung bewegt die Ressource 1010 tatsächlich von der Partition 1 (1000) zur Partition 2 (1002), wie es schematisch mit dem Pfeil 1028 gezeigt ist, so dass die Ressource nunmehr in Partition 2 (1002) erscheint, wie es schematisch mit dem Element 1024 dargestellt ist.
Schließlich informiert in Schritt 910 die Betriebssystem-Instanz 1 (1008) in Verbindung mit der Konsole 1 (1006) die Betriebssystem-Instanz 2 (1018) in Verbindung mit der Konsole 2 (1016) über den Transfer, so dass die Betriebssystem-Instanz 2 (1018) mit der Verwendung der Ressource beginnen kann. Die Routine endet in Schritt 912. Dieser abschließende Schritt des Vorgangs ist in 10E dargestellt, bei dem die Betriebssystem-Instanz 1 (1008) die Betriebssystem-Instanz 2 (1018) informiert, dass die Ressource 1024 nun verfügbar ist. Dieser Vorgang ist schematisch mit Pfeil 1030 dargestellt und beinhaltet bekannte und herkömmliche Zwischenprozess-Kommunikationen. Die Betriebssystem-Instanz 2 (1018) kann anschließend die Ressource 1024 verwenden, wie es schematisch mit dem Pfeil 1032 gezeigt ist.
Wie es zuvor erwähnt wurde, werden Besitzer- und current_owner-Felder in jedem Knoten des Konfigurationsbaumes bereitgestellt, um den Übergang einer Res source von einem zugehörigen und aktiven Zustand zu einem nicht zugehörigen inaktiven Zustand zu verwalten. Lediglich die besitzende Betriebssystem-Instanz einer Ressource kann die Zuweisung der Ressource aufheben, indem sie das Besitzerfeld auf Null stellt. Lediglich Ressourcen, die Null-Besitzer- und current_owner-Felder haben, können einer neuen Partition oder Gemeinschaft zugewiesen werden. Während einer Ressourcen-Migration werden die HWRPBs und die Konfigurationsbäume zusammen abgeändert, um automatisch zu verhindern, dass eine Instanz eine falsche Ansicht der Konfiguration bekommt. In ähnlicher Weise muss ein "Hot-Swap" auch von atomischen und koordinierten Abänderungen an den HWRPBs und den Konfigurationsbäumen begleitet werden.
Wird eine Zuweisung der Ressource aufgehoben, kann das besitzende Betriebssystem wählen, die Zuweisung des Besitzerfeldes oder sowohl des Besitzer- als auch des current_owner-Feldes aufzuheben. Die Entscheidung für welches Feld die Zuweisung aufgehoben werden soll, basiert auf der Fähigkeit des besitzenden Betriebssystems, die Verwendung der Ressource vor der Aufhebung der Zugehörigkeit zu unterbrechen. In dem Fall, in dem ein Neustart erforderlich ist, um die Zugehörigkeit aufzuheben, wird das Besitzerfeld gelöscht aber bleibt das current_owner-Feld unverändert. Wenn die besitzende Betriebssystem-Instanz neustartet, kann das Konsolen-Programm in der Partition so beschaffen sein, dass es beliebige current_owner-Felder für Ressourcen löscht, die während der Initialisierung Null-Besitzerfelder haben.
In dem Fall, in dem die Ressource unter Betriebssystem-Instanzen gemeinsam genutzt wird, die ein Teil der Gemeinschaft sind, müssen die Betriebssysteminstanzen zusammenarbeiten, um die Zuweisung der Ressource aufzuheben. Diese Aufhebung wird durch die Instanzen verwaltet, die Teil der Gemeinschaft sind.
Die Zugehörigkeit einer Ressource wird durch die Änderung des Konfigurationsbaumes verändert. Es müssen bestimmte Regeln befolgt werden, wenn der Konfigurationsbaum geändert wird. Sie enthalten:

1) Wenn das Konfigurationsfeld eines Konfigurationsbaum-Knotens zum Baum-Hardware-Wurzelknoten verweist, ist die entsprechende Ressource in der Lage, unabhängig einer beliebigen Gemeinschaft oder Partition zugewiesen zu werden.
2) Wenn das Konfigurationsfeld dieses Knotens nicht auf den Baum-Hardware-Wurzelknoten verweist, müssen, wenn die Ressource einer Partition zugewiesen wird, sämtliche Abkömmlinge des entsprechenden Baum-Knotens abgeändert werden, so dass sie derselben Partition zugewiesen werden, und müssen sämtliche Baumknoten in der Elternkette vom Baumknoten, der zum Konfigurations-Knoten geändert wird, denselben Partitions- oder Gemeinschafts-Besitzer haben. Der Konfigurations-Knoten muss eine Ahne des Knotens sein, der geändert wird und durch die folgenden Elternverweise erreichbar sein.

Wenn die Zugehörigkeit eines Hardware-Knotens an eine Gemeinschaft abgegeben wird, müssen sämtliche Nachkommen entweder der Gemeinschaft, einer Partition in der Gemeinschaft, zugehörig sein oder nicht zugehörig sein. Ist der Konfigurationsverweis nicht die Hardwarewurzel, müssen sämtliche Knoten in der Elternkette von dem Knoten, der verändert wird, zum Konfigurationsknoten ebenfalls denselben Gemeinschafts-Besitzer haben. Der Konfigurations-Knoten muss ein Ahne des Knotens sein, der geändert wird, und von den folgenden Elternverweisen erreichbar sein.
Hardware-Komponenten, wie etwa eine CPU, können frei unabhängig arbeiten. In diesem Fall legt der Konfigurationsverweis die Hardware-Wurzel fest. Die Komponenten können jedoch auch aus anderen Komponenten bestehen, die nicht unabhängig arbeiten können. Beispielsweise können die I/O-Controller an einem PCI-Bus nicht vom PCI-Bus trennbar sein.
Einige Hardware-Komponenten, wie etwa der Speicher, können von mehreren Partitionen gemeinsam genutzt werden. Dies wird durch das Besitzerfeld ausgedrückt, das auf eine Gemeinschaft verweist. Partitionen in der Gemeinschaft können dann den Zugriff auf die Komponente gemeinsam nutzen. Die Abkömmlinge der Hardware-Komponente, die gemeinsam genutzt wird, können einen Besitzer festlegen, der ein Abkömmling ist. Beispielsweise kann ein Speicher-Teilsystem einer Gemeinschaft zugehörig sein. In diesem Fall gehört der Speicher-Controller, der die Hardware-Aspekte des Speichers einschließlich der Fehlerhandhabung ausdrückt, zu einer Partition in der Gemeinschaft, wobei der Speicher-Deskriptorknoten zur Gemeinschaft gehören kann und seine Fragmente sowohl zu den Gemeinschaften (gemeinsam genutzt) als auch zu Partitionen (privat) gehören können.
Alternative Ausführungsformen
Es sind andere Migrationsszenarien möglich. Beispielsweise könnte eine Systemverwaltungseinrichtung die erste Betriebssystem-Instanz anweisen, eine Ressource stillzulegen und anschließend die Ressource in den "nicht zugewiesenen" Zustand versetzen. Einige Zeit später könnte eine zweite Instanz einen Bedarf an der Ressource entdecken und sie aus dem Vorrat nicht zugewiesener Ressourcen entfernen. Alternativ könnte die Systemverwaltungseinrichtung die zweite Instanz anweisen, die Ressource zuzuordnen. Alternativ könnte die Systemrichtlinie eine Stapelverarbeitung veranlassen, zu einer vorbestimmten Zeit auf der ersten Instanz abzulaufen, die einseitig eine bestimmte Ressource stilllegen und zu einer zweiten Instanz übertragen würde. Bei beiden dieser letztgenannten Beispiele gibt es keine explizite Kommunikation zwischen den Instanzen, die die Ressource betrifft, wenngleich es deutlich ein bestimmtes menschliches Eingreifen oder eine Richtlinie gibt, die die gesamte Verwendung von Ressourcen koordiniert.
Bei einem weiteren Ansatz würden Instanzen eine Ressource aus dem nicht zugewiesenen Vorrat zuteilen, wenn ihre Bedürfnisse dies erfordern. Sind sie mit der Ressource fertig, geben sie diese zum nicht zugewiesenen Vorrat zurück. Ist der Vorrat leer, muss eine Instanz mit ihrer dann existierenden Zuweisung der Ressource arbeiten. Somit haben wir einen gemeinsamen Vorrat, wobei jedoch kein Anfrage-/Freigabe-Protokoll zwischen Instanzen erforderlich ist. Andere Aspekte, wie etwa die spezifischen Anweisungen, die verwendet werden, um eine spezielle Funktion zu erreichen, wie auch andere Modifikationen am Konzept der Erfindung sollen durch die beigefügten Ansprüche abgedeckt sein.
C. SOFTWARE-PARTITIONIERTES MULTIPROZESSOR-SYSTEM MIT FLEXIBLEN EBENEN GEMEINSAM GENUTZTER RESSOURCEN (111–15)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen miteinander elektrisch verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen ist durch Software in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung durch Zuweisen von Ressourcen mit Hilfe einer Konfigurations-Datenstruktur, wie etwa dem Konfigurationsbaum, ausgeführt.
Da die Software logisch CPUs, Speicher und I/O-Anschlüsse partitioniert, indem sie diese einer Partition zuweist, können keine, einige oder sämtliche Ressourcen als gemeinsam genutzt unter mehreren Partitionen gekennzeichnet werden. Jeder einzelnen Betriebs-Instanz werden im allgemeinen die Ressourcen zugeordnet, die sie benötigt, um unabhängig ausgeführt zu werden, wobei diese Ressourcen als "privat" gekennzeichnet werden. Andere Ressourcen, insbesondere der Speicher, können mehr als einer Instanz zugewiesen und gemeinsam genutzt werden. Der gemeinsam genutzte Speicher ist cache-kohärent, so dass Instanzen eng gekoppelt werden können und Ressourcen gemeinsam nutzen können, die normalerweise einer einzigen Instanz, wie etwa verteilten Verriegelungseinrichtungen und Cluster-Zwischenverbindungen, zugeordnet sind.
Neu hinzugefügte Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Be triebssystemen verwendet werden, die innerhalb der Maschine ablaufen, indem die Konfiguration abgeändert wird.
Unter Verwendung des oben beschriebenen Computersystems können unterschiedliche Systemkonfigurationen einfach dadurch erreicht werden, dass der Konfigurationsbaum in geeigneter Weise abgeändert wird. 11 ist eine Übersicht, die zeigt, wie die architektonische Beschreibung aussieht, wenn das Computersystem der Erfindung auf einer Maschine instanziiert wird. Dieses Beispiel ist eine Neun-CPU-SMP-Maschine 1100, die in drei Partitionen 1101, 1102 und 1104 partitioniert wurde. Jede Partition hat eine oder mehrere CPUs (Gruppen 1106, 1108 und 1110) und einige private I/O-Ressourcen (gekennzeichnet mit 1112, 1114 und 1116) und last eine Instanz eines Betriebssystems ablaufen (schematisch mit 1118, 1120 und 1122 gekennzeichnet). Die Betriebssysteme können drei Kopien desselben Betriebssystems oder drei unterschiedliche Betriebssysteme sein. Der Speicher in diesem System ist cache-kohärenter, gemeinsam genutzter Speicher. Der gemeinsame Speicher 1124 wurde in drei Segmente privaten Speichers 1126, 1128 und 1130, eines für jede Betriebssystem-Instanz, partitioniert, und der Rest ist 1132 ist gemeinsam genutzter Speicher für alle drei Betriebssysteminstanzen, die diesen zusammenwirkend nutzen.
Eine Konfiguration, wie etwa jene, die schematisch in 11 gezeigt ist, kann durch geeignete Einträge im Konfigurationsbaum erzeugt werden, der in 3 und 4 gezeigt ist. Was erzeugt wurde, ist das Äquivalent dreier physikalischer Computer innerhalb eines einzigen Computers. Dieser Aufbau ist die Basis für eine Ausführungsform des Computersystems der Erfindung – mehrere unabhängige Instanzen von Betriebssystemen, die zusammenwirkend auf einem einzigen Computer ausgeführt werden. Das Computersystem der Erfindung ist ein Satz koordinierter, heterogener Betriebssysteme in einem einzigen Computer, die über einen gemeinsam genutzten Speicher kommunizieren. Eine Instanz des Betriebssystems in einem derartigen System kann mit anderen Betriebssysteminstanzen innerhalb desselben Computersystems oder mit Betriebssysteminstanzen in anderen Computersystemen geclustert sein.
Eine beliebige Instanz in einem Betriebssystem im Computersystem der Erfindung kann eine SMP-Konfiguration sein. Die zahl der CPUs ist Teil der Definition einer Instanz und wird durch die Konfigurationsbaum-Einträge bestimmt. Da eine Instanz im System der Erfindung ein vollständiges Betriebssystem ist, verhalten sich sämtliche Applikationen in derselben Weise, wie sie dies auf einem herkömmlichen Computer mit einer Instanz tun würden. Beispielsweise laufen existierende Einzelsystem-Applikationen ohne Änderungen an Instanzen in einem Computersystem der Erfindung. Existierende Cluster-Applikationen laufen ebenfalls ohne Änderungen auf geclusterten Instanzen in einem Betriebssystem innerhalb des Systems. Das System besser verfügbar als das herkömmliche Einzelsystem-Ansicht-SMP-System, da mehrere Instanzen von Betriebssystemen im System laufen. Wenn eine einzelne Instanz fehlschlägt, können demzufolge andere Instanzen weiterhin trotz des Hardware- oder Software-Fehlers ablaufen, der den Fehler verursachte.
In einem derartigen System ist der Speicher 1124 in private (1126, 1128 und 1130) und gemeinsam genutzte Bereiche (1132) logisch partitioniert. Als Minimum hat jede Betriebssystem-Instanz ihren eigenen privaten Speicherabschnitt. Keine andere Instanz kann in diesen physikalischen Speicherabschnitt mit Ausnahme unter Anweisung der besitzenden Betriebssystem-Instanz abbilden. Ein Teil des gemeinsam genutzten Speichers 1124 ist für Instanzen der Betriebssysteme (1118, 1120 und 1112) verfügbar, um miteinander zu kommunizieren, wobei der Rest des gemeinsam genutzten Speichers für Applikationen verfügbar ist.
Beim System der Erfindung ist das I/O-Teilsystem ebenfalls skalierbar. Da es mehrere "primäre" CPUs im System gibt – eine für jede Instanz – gibt es einen besseren Lastenausgleich der I/O-Arbeitslast. Darüber hinaus können I/O-Controller die Verteilung von I/O auf sekundäre CPUs in einem SMP-System unterstützen, wodurch die I/O-Arbeitslast weiter ausgeglichen wird.
Wenngleich es drei getrennte Betriebssystem-Instanzen in 11 gibt, gibt es eine Erwartung des Zusammenarbeitens zwischen den Instanzen. Eine derartige Zusammenarbeit kann in drei weit gefassten Kategorien von Berechungsmodellen definiert werden:

1) Keine gemeinsame Nutzung – die Betriebssystem-Instanzen nutzen keine Ressourcen gemeinsam, stimmen jedoch darin überein, sich einander nicht zu stören.
2) Teilweise gemeinsam genutzt (etwas wird gemeinsam genutzt) – die Betriebssystem-Instanzen stimmen darin überein, zu kooperieren und begrenzte Ressourcen, wie etwa Speicher oder Speicherung, gemeinsam zu nutzen.
3) Alles gemeinsam genutzt – die Betriebssystem-Instanzen stimmen darin überein, vollständig zu kooperieren und sämtliche verfügbaren Ressourcen bis zu dem Punkt gemeinsam zu nutzen, an dem die Betriebssysteminstanzen eine einzige kohäsive Einheit für das Netzwerk darstellen. Beispielsweise können die Betriebssystem-Instanzen für den Benutzer als ein Open VMS Cluster erscheinen.

Wenngleich einige Betriebssystem-Instanzen Ressourcen gemeinsam nutzen, können eine oder mehrere Betriebssystem-Instanzen insgesamt eine Softwareisolation von allem Anderen ausführen. Eine Instanz, die ohne die gemeinsame Nutzung von Ressourcen existiert, wird eine unabhängige Instanz genannt und nimmt in keiner Weise an der Verwendung gemeinsam genutzten Speichers teil. Insbesondere greifen weder das Basisbetriebssystem noch dessen Applikationen auf den gemeinsam genutzten Speicher zu. Das Computersystem der Erfindung könnte lediglich aus unabhängigen Instanzen bestehen; ein derartiges System würde der herkömmlichen Partitionierung vom Typ eines Großrechners gleichen.
12 zeigt, wie das System der Erfindung konfiguriert sein kann, um ein Berechnungsmodell "keiner gemeinsamen Nutzung" zu unterstützen. Bei diesem Beispiel wurden drei Partitionen 1206, 1210 und 1214 innerhalb einer einzigen Maschine 1200 erzeugt, auf der jeweils eine Instanz eines Betriebssystems läuft. Die verfügbaren zwölf CPUs wurden willkürlich gleich zwischen den Partitionen bei diesem Beispiel 1206, 1210 und 1214 unterteilt, wie es dargestellt ist. Der verfügbare Speicher wurde in privaten Speicher unterteilt und den Instanzen zugewiesen. In 12 sind private Speicherunterteilungen 1216, 1218 und 1220 darge stellt. Sowohl der Code als auch die Daten für jede Instanz sind im privaten Speicher gespeichert, der dieser Instanz zugewiesen ist. Wenngleich der Speicher 1216, 1218 und 1220 als gleichmäßig unterteilt in 12 dargestellt ist, unterstützt die Architektur der Erfindung die willkürliche Unterteilung des Speichers zwischen Instanzen. Wenn eine Partition große Speicheranforderungen hat und eine weitere begrenzten Speicherbedarf hat, kann somit das System beiden gerecht werden, um die Verwendung des verfügbaren Speichers zu maximieren.
Jede Partition hat zudem private I/O-Controller/-Platten, die als I/O-Abschnitte 1204, 1208 und 1212 dargestellt sind. Unmittelbar dann, wenn ein Speicher willkürlich geteilt wird, trifft diese Charakteristik für die I/O-Schaltkreise zu. Bei der Anordnung "keiner gemeinsamen Nutzung", die in 12 gezeigt ist, sind die verfügbaren I/O-Ressourcen für jede Partition privat, müssen jedoch nicht gleichmäßig geteilt sein. Die Partitionen 1206, 1210 und 1214 können über eine physikalische Verknüpfung 1202 innerhalb der Maschine miteinander vernetzt sein, wobei diese Verknüpfung von der Maschine zu anderen Computern erweitert werden kann.
Was gerade erzeugt wurde, ist das Äquivalent von drei physikalisch getrennten Maschinen, die miteinander vernetzt sind. Der Unterschied zwischen einem herkömmlichen Computersystem und dem System der Erfindung besteht darin, dass es anstelle von drei physikalischen Kästen lediglich einen Kasten gibt. Zudem muss die exakte Konfiguration jeder Partition nicht festgelegt sein, solange die Maschine nicht eingesetzt ist. Ein weiteres einzigartiges Merkmal des Systems der Erfindung besteht in der Fähigkeit die Zahl/Größe der Partitionen nach dem Einsatz der Maschine dynamisch zu konfigurieren.
13 zeigt das System der Erfindung, das als Modell mit teilweise gemeinsamer Nutzung konfiguriert ist, wobei die Partitionen Speicher gemeinsam nutzen. In 13 wurde Elementen, die den Elementen in 12 entsprechen, entsprechende Bezugszeichen gegeben. Beispielsweise wurde die Maschine 1200 in 12 in 13 als Maschine 1300 gekennzeichnet. Wie zuvor, hat jede Partition 1306, 1310 und 1314 ihren eigenen privaten Speicherabschnitt 1316, 1318 bzw. 1320, in dem der Code und die Daten für diese Instanz gespeichert sind. Es gibt jedoch bei dieser Konfiguration auch einen gemeinsam genutzten Speicherabschnitt 1322, in dem Daten und/oder ein Code gespeichert sind, auf die von sämtlichen Instanzen 1306, 1310 und 1314 zugegriffen werden kann. Die drei Instanzen 1306, 1310 und 1314 sind durch eine Zwischenverbindung 1302 zudem vernetzt.
Der Vorteil der Konfiguration, die in 13 gezeigt ist, besteht darin, dass nun große gemeinsam genutzte Cache-Speicher (wie etwa Datenbanken oder Dateisysteme) erzeugt werden und gemeinsam von mehreren Instanzen verwendet werden können. Das System hat zudem den Vorteil, dass eine Instanz eines Betriebssystems die Konfiguration deaktivieren oder verlassen kann und bei erneuter Teilnahme erneut in einen weiterhin aktiven Cache-Speicher abbilden kann. Wenn die Cache-Speicher größer werden, ist die Fähigkeit, in einen bestehenden Speicher abzubilden, extrem wichtig, da es sehr viel Zeit in Anspruch nimmt, sämtliche Einträge in sehr großen Cache-Speichern in einen privaten Speicherraum zu laden.
14 zeigt das System der Erfindung, das so beschaffen ist, das es als Computer-System einer "vollständigen gemeinsamen Nutzung" arbeitet. Wie in 13, wurden Elementen in 14, die ähnlichen Elementen in 12 und 13 entsprechen, entsprechende Bezugszeichen gegeben. Jede Partition 1406, 1410 und 1414 hat weiterhin ihren eigenen privaten Speicher 1416, 1418 bzw. 1420, in dem ein Code und Daten für diese Instanz gespeichert sind. Es gibt zudem einen gemeinsam genutzten Speicherabschnitt 1422, in dem Daten gespeichert sind. Die drei Instanzen sind durch eine Zwischenverbindung 1402 vernetzt, wobei es jedoch auch eine Speicher-Zwischenverbindung 1424 und eine Cluster-Zwischenverbindung 1426 gibt. Die Konfiguration des Systems für eine Berechnung, bei der alles gemeinsam genutzt wird, bringt zudem die folgenden Vorteile:

1) eine verteilte Verriegelungs-Verwaltungseinrichtung (nicht gezeigt) kann gemeinsam genutzten Speicher 1422 verwenden, um ihren Verriegelungscache (nicht gezeigt) zu speichern, wodurch das Verriegelungs-Leistungsverhalten verbessert wird.
2) eine Cluster-Zwischenverbindung 1428 kann in einem gemeinsam genutzten Speicher 1422 plaziert werden, anstelle unabhängige Hardware zu verwenden, wodurch das Leistungsverhalten der Cluster-Kommunikation erhöht wird, sofern die Instanzen 1406, 1410 und 1414 geclustert sind.
3) Partitionen können für hoch spezialisierte Funktionen erzeugt werden. Es kann beispielsweise eine Partition ohne I/O-Controller (nicht gezeigt) erzeugt werden, wodurch sie tatsächlich zu einer "Berechnungsmaschine" wird.

Mit dem System der Erfindung besteht die Möglichkeit, alle drei Berechungsmodelle, die in 12, 13 und 14 gezeigt sind, innerhalb eines einzigen Computer-Kastens durch geeignete Konfiguration von Partitionen ablaufen zu lassen. Das heißt, einige Partitionen können als Computer "ohne gemeinsame Nutzung" arbeiten. Eine getrennte Gruppe von Partitionen kann als Berechungssystem mit "teilweise gemeinsamer Nutzung" arbeiten, und eine weitere Gruppe von Partitionen kann als Berechnungssystem mit "vollständiger gemeinsamer Nutzung" arbeiten. Zudem ist es für eine gegebene Instanz möglich, mit einem Satz von Instanzen gleichzeitig in einer Konfiguration "teilweiser gemeinsamer Nutzung" und mit einem weiteren (und vollständig getrennten) Satz von Instanzen in einer Konfiguration "vollständiger gemeinsamer Nutzung" zu arbeiten.
Unabhängig vom Berechungsmodell oder der Kombination von Modellen, die in der Architektur der Erfindung laufen, ist die Fähigkeit der dynamischen Neuzuordnung von Ressourcen möglich, ohne die Integrität einer der Betriebssystem-Instanzen zu beeinflussen. Insbesondere wird die Fähigkeit unterstützt, CPUs und Speicher zwischen Partitionen zu migrieren.
Somit bietet das System die Möglichkeit einer lineareren Skalierung von Systemressourcen, da die System-Verwaltungseinrichtungen Ressourcen zuweisen können, um Applikationserfordernissen gerecht zu werden, wenn die Anforderungen des Unternehmens wachsen oder sich ändern. Wird eine CPU einer Computerkonfiguration der Erfindung hinzugefügt, kann sie einer beliebigen Instanz des Betriebssystems zugewiesen werden und später während des Systembetriebs erneut zugewiesen werden, so dass ein "Trial-and-Error"-Verfahren der Zuweisung von Ressourcen eine gangbare Strategie ist. Insbesondere können System-Verwaltungseinheiten CPUs unter Instanzen von Betriebssystemen migrieren, bis die wirkungsvollste Kombination von Ressourcen gefunden ist. Sämtliche Instanzen von Betriebssystemen und deren Applikationen laufen weiter ab, wenn CPUs migriert werden. Schließlich bietet die Verteilung von Interrupts über Instanzen zahlreiche I/O-Konfigurationsmöglichkeiten; beispielsweise kann die Arbeitslast derart partitioniert werden, dass bestimmter I/O-Verkehr auf speziellen Instanzen ausgeführt wird.
Das System der Erfindung kann zudem Ressourcen übertragen, während das System läuft. Somit kann eine Komponente, wie etwa eine CPU, von einer Instanz zu einer weiteren bewegt werden, während die elektrische Versorgung des Systems eingeschaltet bleibt und der Rest des Hardware-Systems weiterhin läuft. Dies ist in 15 dargestellt. Wie bei 13 und 14, wurde Elementen in 15, die ähnlichen Elementen in 12, 13 und 14 entsprechen, entsprechende Bezugszeichen gegeben. 15 zeigt die Migration von CPUs 2 und 3 sowie CPUs 8 und 9 in die Instanz 1510, wie es schematisch mit den Pfeilen 1528 bzw. 1530 gezeigt ist. Diese Migration erzeugt eine Instanz 1510 mit acht CPUs. Bei einer derartigen Anordnung müssen die Instanzen nicht in einer Konfiguration der "vollständigen gemeinsamen Nutzung" arbeiten; die Instanzen können auf einer der Ebenen der gemeinsamen Nutzung von Ressourcen arbeiten und trotzdem weiterhin die Ressourcenmigration vol unterstützen.
Das System der Erfindung gestattet die Stilllegung von einzelnen I/O-Teilsystemen aufgrund der Tatsache, dass eine Betriebssystem-Instanz, die auf einer Partition läuft, abgeschaltet werden kann, ohne die übrigen Partitionen zu beeinflussen. Wenn die Hardware mit Ausnahme der Komponente, die einem Swapping unterzogen wird, weiterhin läuft, behält die Software im allgemeinen so viele Instanzen und deren laufende Applikationen wie möglich. Die Erfindung unterstützt zudem ein "Hot-Inswapping", das ein Hardware-Merkmal ist, das es Ressourcen gestattet, dem System hinzugefügt zu werden, während das System läuft und die elektrische Spannung anliegt. Eine Beispiel des Hot-Inswappings ist zusätzlicher Speicher. Vorausgesetzt eine Betriebssystem-Instanz auf einer speziellen Partition ist in der Lage, zusätzlichen Speicher dynamisch abzubilden, kann das System den einem Hot-Inswapping unterzogenen Speicher in die aktiven Berechungsumgebungen absorbieren, die auf der Maschine laufen.
D. VIRTUELLE RESSOURCEN-HANDHABUNG IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (16–18)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardwaregrenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Die einzelnen Instanzen enthalten jeweils einen separaten Eintrag sämtlicher Verarbeitungsressourcen des Systems. Jede der Instanzen kategorisiert die Prozessoren auf der Basis ihres jeweiligen Betriebsstatus relativ zur Instanz. Bei einer bevorzugten Ausführungsform enthält eine Instanz Einträge darüber, ob jede CPU kompatibel für den Betrieb mit der Instanz ist, ob sie von der Instanz gesteuert wird und ob sie für den SMP-Betrieb innerhalb der Instanz verfügbar ist. Diese unterschiedlichen Betriebszustände repräsentieren eine hierarchische Kategorisierung der CPUs des Systems, wobei das System auf zusätzliche Kategorien anpassbar ist. Ein zusätzlicher Zustand, der verwendet werden kann, zeigt an, ob ein Prozessor gewählt worden ist, um unverzüglich Verarbeitungsaktivitäten zu beginnen, wenn zuerst ein Beitritt zur Instanz erfolgt.
Bei der bevorzugten Ausführungsform wird die Mitgliedschaft der CPUs in einer der unterschiedlichen Kategorien des Betriebszustandes von jeder Instanz aufgezeichnet, die Bitvektoren für jede Kategorie enthält, wobei wenigstens ein Bit jedes Bitvektors dem Mitgliedszustand einer der CPUs in dieser Kategorie entspricht. Normalerweise hat jeder Bitvektor ein Bit für jede der CPUs, so dass beispielsweise ein Bitvektor, der für die CPU-Steuerung durch die in Frage kommende Instanz kennzeichnend ist, ein erstes Bit hat, das auf einen ersten Aussagegrad eingestellt ist, wenn eine erste entsprechende CPU von der Instanz gesteuert wird. Wird die CPU nicht von der Instanz gesteuert, ist das Bit auf einen zweiten Aussagegrad eingestellt. Mit einem Bit, das für jede der CPUs kennzeichnend ist, stellt dieser Bitvektor anschließend Kennzeichnungen für jede der CPUs bereit, die aussagen, welche sich unter Steuerung der Instanz befinden. In ähnlicher Weise stellen andere Bitvektoren Kennzeichnungen für jede der CPUs bereit, wobei diese Kennzeichnungen beispielsweise anzeigen, welche CPUs für den Betrieb mit der Instanz kompatibel sind, welche für die Instanz für den SMP-Betrieb verfügbar sind und welchen es gestattet sein würde, an SMP-Verarbeitungsaktivitäten unmittelbar nach der Initialisierung teilzunehmen. Auf diese Weise kann jede der Instanzen individuell sämtliche Verarbeitungsressourcen und deren Betriebszustände relativ zur Instanz verfolgen.
Bei einer alternativen Ausführungsform werden Kennzeichnungen, die die Betriebszustände von Verarbeitungsressourcen relativ zu den Instanzen des Sys tems kennzeichnen, in einem Speicherbereich gehalten, auf den sämtliche Instanzen zugreifen können. Insbesondere werden Informationen bereitgestellt, die die Kompatibilität eines Prozessors mit jeder der unterschiedlichen Instanzen betreffen. Dadurch kann jede Instanz identifizieren, ob ein gegebener Prozessor für den Transfer zu einer speziellen Instanz geeignet sein kann.
Virtuelle Ressourcen-Verwaltung
Bei einer bevorzugten Ausführungsform der Erfindung sind die CPU-Ressourcen für das Computersystem in einer speziellen Hierarchie im Bezug auf jede Instanz angeordnet. Das heißt, die CPUs des Systems werden durch jede Instanz identifiziert und jede Instanz kategorisiert die CPUs gemäß ihrer eigenen Verwendung oder deren potentieller Verwendung. Dies wird im folgenden detaillierter Erläutert.
Bei der bevorzugten Ausführungsform hält jede der Instanzen einen Eintrag der CPUs im System, der sie in jeweils einen von drei Sätzen kategorisiert: den "potentiellen" Satz, den "Konfigurations"-Satz und den "aktiven" Satz. Aus dem Blickwinkel einer gegebenen Instanz, deckt der potentielle Satz sämtliche CPUs ab, die möglicherweise in dieser Instanz zu einer beliebigen Zeit ausgeführt werden. Dieser enthält normalerweise sämtliche CPUs im System, mit Ausnahme jener, die zur Konfigurations- oder Überprüfungsebene gehören, wodurch sie mit der Instanz und/oder der Partition inkompatibel werden, auf der sie läuft. Jede Instanz macht eine Bestimmung jener CPUs im System, die kompatibel mit ihr sind, und enthält diese in ihrem potentiellen Satz.
Der Konfigurationssatz enthält sämtliche der CPUs, die für die gegebene Instanz von der Instanz gesteuert werden. Das heißt, der Konfigurationssatz enthält alle CPUs, die von der Instanz gesteuert (verwaltet) werden und die momentan am SMP-Betrieb teilnehmen oder in der Lage sind, an diesem in der Zukunft teilzunehmen. Sobald die Instanz die Steuerung der CPU erlangt hat (was durch die Einstellung des "current_owner"-Bits der CPU in den Je-CPU-Bits des HWRPB für die Partition angezeigt ist, auf der die Instanz läuft), gibt es eine Periode, während der sie sich selbst für einen Betrieb mit der neuen Instanz initialisiert. Während dieser Periode nimmt die CPU nicht am SMP-Betrieb teil, ist jedoch gleichwohl Teil des Konfigurationssatzes für diese Instanz. Sobald die Initialisierung abgeschlossen ist, macht die CPU eine Anfrage zu Teilnahme am SMP-Betrieb. Sobald sie teilnimmt, wird die CPU ebenfalls als Teil des aktiven Satzes angesehen. Der aktive Satz enthält sämtliche CPUs, die am SMP-Betrieb für die Instanz teilnehmen. Eine CPU ist in der aktiven Betriebsart in der Lage, Anweisungen aus der Anweisungs-Warteschlange als Teil des Zeitplanungsmodells der Instanz abzuziehen.
16 ist eine schematische Darstellung zahlreicher Partitionen 1600, 1602, 1604 und wie die Instanz für jede der Partitionen die CPUs als Sätze organisiert hat. Wenngleich dieses Beispiel lediglich acht unterschiedliche CPUs verwendet, wird der Fachmann verstehen, dass eine beliebige Anzahl von CPUs das System bilden können. Beim Beispiel von 16 hat jede der Instanzen jede der CPUs 0 bis 7 als sich in ihrem potentiellen Satz befindend identifiziert. Somit repräsentieren diese entweder sämtliche CPUs im System, oder beliebige andere CPUs im System sind nicht mit einer beliebigen der Instanzen kompatibel. Es können natürlich andere Beispiele existieren, bei denen sich eine CPU im potentiellen Satz einer Instanz befindet, jedoch nicht in dem einer weiteren Instanz, vorausgesetzt, die beiden Instanzen haben unterschiedliche Kompatibilitätsanforderungen.
Die Konfigurationssätze für die Instanzen auf den Partitionen 1600, 1602, 1604 unterscheiden sich von jeder Instanz. Dies muss immer der Fall sein, da lediglich eine Instanz die Steuerung einer CPU-Ressource zu einem gegebenen Zeitpunkt haben kann. Wie es dargestellt ist, befinden sich die CPU 0, CPU 2, CPU 3 und CPU 7 im Konfigurationssatz der Instanz, die auf der Partition 1600 läuft. Die CPU 1 und die CPU 5 befinden sich im Konfigurationssatz der Instanz, die auf der Partition 1602 läuft. Schließlich befinden sich die CPU 4 und die CPU 6 im Konfigurationssatz der Instanz, die auf der Partition 1604 läuft. Somit werden die CPUs jeweils von diesen unterschiedlichen Instanzen gesteuert.
Die CPUs in den aktiven Sätzen der drei Instanzen, die jeweils auf den Partitionen 1600, 1602, 1604 laufen, sind dieselben, wie jene in den Konfigurationssätzen für jene Instanzen, mit der Ausnahme von CPU 2, die sich lediglich im Konfigurati onssatz der Instanz von Partition 1600 befindet. In diesem Fall kann davon ausgegangen werden, dass die CPU 2 kürzlich zur Steuerung der Instanz auf Partition 1600 bewegt wurde und eine Initialisierungsstufe durchläuft, bevor sie einen SMP-Betrieb durchläuft. Sobald sie den anderen CPUs des Systems bei tatsächlichen Verarbeitungsaktivitäten beitritt, wird sie Teil des aktiven Satzes für die Instanz von Partition 1600.
Bei der bevorzugten Ausführungsform verfolgt jede der Instanzen den Zustand ihrer Zugehörigkeitsrechte in den CPUs über Gruppen von Bits oder "Bitvektoren". Die Bitvektoren jeder Instanz werden zur Verfolgung der CPU-Teilnahme in diesem potentiellen Satz, des Konfigurationssatzes bzw. des aktiven Satzes der Instanz verwendet. Ein Beispiel hierfür ist schematisch in 17 dargestellt, die schematisch die Bitvektoren für den potentiellen Satz, den Konfigurationssatz und den aktiven Satz der Instanz darstellt, die auf der Partition 1600 laufen.
Wie es in 17 gezeigt ist, kennzeichnet für jede der Gruppen von in Frage kommenden Bits, der Aussagegrad eines Bits die relative Mitgliedschaft einer CPU, die von diesem Bit in einem der drei gekennzeichneten Sätze repräsentiert wird, die von der Instanz erkannt werden. Jedes Bit in einem gegebenen Bitvektor repräsentiert den Status einer der CPUs im Bezug auf diesen Satz. Die Bitvektoren in 17 entsprechen jeweils einem anderen Satz, wobei die einzelne CPU, die von einem gegebenen der Bits identifiziert wird, in der Zeichnung durch das "CPU#"-Etikett über der Darstellung des Bits gekennzeichnet ist. Somit ist für die Instanz, die in 17 gezeigt ist, jede der CPUs ein Mitglied des potentiellen Satzes der Instanz. Diese entspricht der Auflistung von CPUs, die unter der Überschrift "potentieller Satz" der Instanz auf Partition 1600 (16) gezeigt ist. Da in ähnlicher Weise die CPUs 0, 2, 3 und 7 Mitglieder des Konfigurationssatzes der Instanz sind, sind die Bits, die jenen CPUs in 17 entsprechen, jeweils auf "1" eingestellt, während die anderen "0" sind. Schließlich hat der aktive Satz die Bits, die jeweils den CPUs 0, 3 und 7 entsprechen, auf "1" eingestellt, während die verbleibenden Bits "0" sind. Dadurch ist gekennzeichnet, dass sich die CPUs 0, 2, 3 und 7 im Konfigurationssatz der Instanz der Partition 1600 befinden, während sich lediglich die CPUs 0, 3 und 7 in ihrem aktiven Satz befinden.
Die Bitvektoren, die in 17 gezeigt sind, sind auf die Darstellung von acht CPUs beschränkt. Dies dient jedoch lediglich der Beschreibung. Der Fachmann wird erkennen, dass das Computersystem wahrscheinlich weitaus mehr CPUs habe kann und momentan bei der bevorzugten Ausführungsform 64 unterschiedliche Bits für jede Bitgruppe verwendet werden, so dass bis 64 CPUs zulässig sind, wenngleich weitaus mehr hinzugefügt sein können. Weiterhin wird der Fachmann erkennen, dass alternative Verfahren zur Verfolgung des Betriebszustandes von CPUs im Bezug auf die Instanzen des Systems existieren, wobei diese Alternativen als sich im Geltungsbereich der Erfindung befindend erachtet werden.
Die Kategorisierung von CPUs, wie sie oben beschrieben ist, stellt eine hierarchische Aufgliederung von CPU-Sätzen für die Instanzen des Systems bereit. In dieser Hinsicht werden unterschiedliche Betriebsebenen unabhängig von jeder Instanz erkannt, wobei in der Zukunft zusätzliche Ebenen hinzugefügt werden können. Die CPUs, die Mitglieder des Konfigurationssatzes einer gegebenen Instanz sind, entsprechen jenen, für die die Partition, auf der diese Instanz läuft, als current_owner im Konfigurationsbaum gekennzeichnet ist. Jene, die Mitglieder des aktiven Satzes sind, sind nicht nur als momentan zugehörig zur in Frage kommenden Instanz gekennzeichnet, sondern sind zudem Verfügbar, um an der SMP-Verarbeitung teilzunehmen. Somit erweitert die vorliegende Erfindung die Informationsbasis jeder Instanz, indem sie ihr nicht nur anzeigt, welche Verarbeitungsressourcen derzeit für ihre Verwendung bereitstehen, sondern auch welche anderen Prozessoren sich im System als Ganzes befinden, die auf die Instanz übertragen werden können. Dies würde es gestatten, dass die Instanz beispielsweise selektiv Prozessoren von anderen Instanzen anfordern kann, die bekannt werden, um diese zu steuern.
Bei einer alternativen Ausführungsform der Erfindung verwendet jede Instanz einen zusätzlichen Satz, um die CPU-Ressourcen des Systems zu kategorisieren. Dieser zusätzliche Satz wird als "Autostart"-Satz bezeichnet, und er identifiziert jene Prozessoren, die eine Instanz zulässt, um unverzüglich Verarbeitungsaktivitäten zu beginnen, nachdem sie in den Konfigurationssatz eingetreten ist. Wenn eine CPU zu einer neuen Partition bewegt wird, wird sie normalerweise von der neuen Instanz angehalten und muss anschließend auf eine neue Startanweisung von der Instanz warten bevor sie die Verarbeitungsaktivitäten wieder aufnimmt. Ein Prozessor im Autostartsatz würde jedoch nicht von der neuen Instanz angehalten werden und würde bei der Initialisierung unverzüglich anfragen, an der SMP-Verarbeitung teilzunehmen.
18 gleicht 17 dahingehend, dass die darstellt, wie unterschiedliche CPUs mit unterschiedlichen Sätzen durch die Bitvektoren einer gegebenen Instanz identifiziert werden. 18 zeigt zudem eine schematische Darstellung eines Bitvektors, der verwendet wird, um jene Prozessoren zu identifizieren, die sich im Autostartsatz befinden. Wie es dargestellt ist, ist der Autostart-Satz kein Teilsatz für einen beliebigen der anderen Sätze und kann daher über Einstellungen verfügen, die sich entweder von den Konfigurationssätzen oder den aktiven Sätzen unterscheiden. Wenngleich sich die CPU 0 im aktiven Satz befindet und somit momentan an der SMP-Verarbeitung teilnimmt, ist sie kein Mitglied des Autostart-Satzes und wurde demzufolge, als sie sich das erste mal der Instanz anschloss, angehalten und verlangte eine spezielle Startanweisung, bevor sie in der Lage war, an der SMP-Verarbeitung teilzunehmen. Die CPU 5 hingegen befindet sich derzeit nicht im Konfigurationssatz oder im aktiven Satz, sondern ist so identifiziert, dass sie sich innerhalb des Autostartsatzes befindet. Wenngleich die CPU 5 momentan durch eine weitere Instanz im System gesteuert wird, so als ob sie in die Steuerung der Instanz migrieren sollte, für die die Sätze von 18 dargestellt sind, würde sie nicht von der Instanz angehalten werden, sondern würde einer notwendigen Initialisierung unterzogen werden und anschließend versuchen, sich den fortlaufenden Verarbeitungsaktivitäten anzuschließen.
Bei einer weiteren alternativen Ausführungsform könnten die Informationen, die von den oben beschriebenen Sätzen bereitgestellt werden, die für jede Instanz lokal für diese Instanz sind, ebenfalls für sämtliche Instanzen des Systems global verfügbar sein. Durch anordnen sämtlicher eingestellter Informationen für sämtliche Instanzen in einer zentrale Anordnung im gemeinsam genutzten Speicher, kann sämtlichen Instanzen Zugriff auf Informationen gegeben werden, die betreffen, welche der Prozessoren in welcher Instanz kompatibel waren. Mit diesen Informationen könnte eine Verschiebemigration eines Prozessors, der nicht für eine spezielle Anfrage von einer gegebenen Instanz verantwortliche war, zu einer In stanz verwiesen werden, für die dieser Prozessor als kompatibel bekannt war. Somit würde eine Situation, in der ein Prozessor zu einer Instanz migriert würde, mit der er nicht kompatibel wäre, vermieden werden. Weiterhin könnte, wenn dies gewünscht würde, eine Instanz, die eine zusätzliche Ressource anfordert, dies als eine allgemeine Rundsendeanfrage anstelle einer zielgerichteten Anfrage tun und könnte auf eine weitere Instanz zurückgreifen, die dieser Anfrage dient, um lediglich eine Ressource zu migrieren, von der sie wüsste, dass sie mit der anfragenden Instanz kompatibel ist. Eine Abänderung dieser Ausführungsform würde als globale Anordnung lediglich die Informationen bereitstellen, die den potentiellen Satz jeder Instanz betreffen. Jede Instanz würde dadurch ihren eigenen Satz von lokalen Informationen haben, um den Status ihrer eigenen Ressourcen zu bestimmen, und würde Zugriff auf die globale Anordnung für Kompatibilitätsinformationen haben, die sämtliche Instanzen im System betreffen.
E. DYNAMISCHE GEMEINSAME NUTZUNG VON SPEICHER IN EINEM MULTIPROZESSORSYSTEM (1–8B)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen des Betriebssystems zusammenwirkend in einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird adaptiv durch Software in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems ablaufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert Software logisch und adaptiv CPUs, Speicher und I/O-Anschlüsse, indem sie sie zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen in eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Software-Funktion; es sind keine Hardware-Einschränkungen erforderlich. Jede Instanz verfügt über die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die innerhalb der Maschine laufen, in dem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende APMP-System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Die Ausführungsumgebung einer einzelnen Kopie eines Betriebssystems oder einer Instanz wird als Partition bezeichnet. Eine Gemeinschaft ist eine Gruppierung von Partitionen, die Ressourcen gemeinsam nutzen können. Der Speicher kann für eine spezielle Partition privat sein, oder kann von Partitionen innerhalb einer Gemeinschaft gemeinsam genutzt werden. Wenn ein APMP-Computersystem ausgebildet wird, liest eine erzeugende Instanz einen Konfigurationsbaum und baut Verwaltungsstrukturen für die gemeinsam genutzten Ressourcen, einschließlich des Speichers, auf, die der Gemeinschaft zugehörig sind. Ein einziges System kann eine oder mehrere Gemeinschaften haben, die jeweils ihre eigene Darstellung innerhalb des Konfigurationsbaumes haben.
Die Konfigurationssoftware wählt eine Gruppe von Seiten gemeinsam genutzten Speichers, die der Synchronisationspunkt für ein APMP-Computersystem sein sollen. Diese Seiten enthalten Informationen, die verwendet werden um zu bestimmen, ob andere Instanzen aktive Elemente des APMP-Computersystems sind. Eine Kennzeichnung des Ortes dieser Synchronisationsseiten ist im Konfigurationsbaum gespeichert. Wenn eine Instanz dem APMP-Computersystem beitritt, verwendet sie Informationen innerhalb des Konfigurationsbaumes, um die gemeinsam genutzten Seiten abzubilden. Aus den Inhalten der gemeinsam genutzten Seiten kann die Instanz bestimmen, ob sie einem aktiven APMP-Computersystem beitritt, oder ein APMP-Computersystem erzeugt. Erzeugt die Instanz ein APMP-Computersystem, kann sie die Seiten, die zum Synchronisieren des APMP-Computersystems verwendet werden, neu konfigurieren, indem sie den Konfigurationsbaum modifiziert. Auf diese Weise kann physikalischer Speicher, der zuvor als Synchronisationspunkt verwendet wurde, aus dem System entfernt werden.
Gemeinsam genutzter Speicher kann in Gruppen, die als Gemeineigenschafts-Partitionen bezeichnet werden, gemäß den Hardware-Eigenschaften des Speichers organisiert werden. Der gemeinsam genutzte Speicher kann Bereichen zugewiesen werden, die gleichzeitig durch eine oder mehrere Betriebssysteminstanzen abgebildet werden können. Der gemeinsam genutzte Speicher kann zudem durch Applikationen abgebildet werden, die auf einer oder mehreren Betriebssysteminstanzen laufen. Der gemeinsam genutzte Speicher kann von einer Betriebssystem-Instanz für die Verwendung als privater Speicher der Instanz "geborgt" werden. Darüber hinaus ist für einen nicht gleichmäßigen Speicherzugriff im Falle des privaten Speichers gesorgt, indem es dem privaten Speicher gestattet ist, zu der Instanz zu gehören, deren CPUs den schnellsten Zugriff auf den Speicher haben.
F. NEUKONFIGURATION DES SPEICHERS IN EINEM MULTIPROZESSORSYSTEM MIT GEMEINSAM GENUTZTEM SPEICHER
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt bezeichnet werden. Gemäß einer Ausführungsform wird die Partitionierung durch Zuweisung von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Anschlüsse, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssystem-Instanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardware-Einschränkungen erforderlich. Jede einzelne Instanz verfügt über die Ressourcen, die sie benötigt um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen und von Instanzen von Betriebssystemen verwendet werden, die innerhalb der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls ohne Neustart des Systems durch Modifizieren des Konfigurationsbaumes geändert werden. Das resultierende APMP-System weist eine Skalierbarkeit, Flexibilität und hohe Leistungsfähigkeit auf.
Der Speicher kann in eine oder aus einer Partition oder Gemeinschaft unter Software-Steuerung neukonfiguriert werden, wobei Hardware-Hot-In-Swapping und -Out-Swapping unterstützt sind. Im allgemeinen kann sich der Speicher in einem von drei Zuständen befinden: privat, gemeinsam genutzt oder nicht zugehörig. Der Speicher ist privat, wenn er von einer einzigen Systempartition "besessen" wird. Der Speicher wird gemeinsam genutzt, wenn er einer Gemeinschaft zugehörig ist. Eine Gemeinschaft ist eine Sammlung einer oder mehrerer Partitionen, die Ressourcen gemeinsam nutzen können. Andernfalls ist er nicht zugehörig. Der Speicher kann zwischen einem beliebigen der drei Zustände direkt rekonfiguriert werden. Beispielsweise kann der Speicher aus privat in einer Partition zu privat in einer weiteren Partition oder von gemeinsam genutzt in einer Gemeinschaft zu privat in einer Partition rekonfiguriert werden. Der Speicher wird in einen nicht zugehörigen Zustand durch eine Betriebssysteminstanz und eine Konsolen-Software, die im Systemkonfigurationsbaum widergespiegelt werden, versetzt, bevor der Speicher einem Out-Swapping oder einem In-Swapping unterzogen werden kann. Eine Seitenrahmenzahl-Datenbank ist derart bemessen, dass sie den gesamten möglichen Speicher enthalten kann, der einem In-Swapping unterzogen wird, wobei hinzugefügte Speicherseiten als Seitenrahmenzahl-Datenbankeintragsseiten verwendet werden können. Demzufolge kann neuer Speicher auf einfache Weise aufgenommen werden. Wie es oben beschrieben wurde, muss sich für ein Out-Swapping des Speichers der Speicher im nicht zugehörigen Zustand befinden. Befindet sich der Speicher, der einem Out-Swapping unterzogen werden soll, entweder in einem gemeinsam genutzten oder in einem privaten Zustand, wird er in den nicht zugehörigen Zustand versetzt, um ein Out-Swapping zuzulassen.
Neukonfiguration des Speichers
Der Aufbau der Seitenrahmenzahl-(PFN-)Datenbank gestattet es dem Speicher, durch Software-Steuerung in die oder aus der Betriebssystem-Instanz neukonfiguriert zu werden. Privater Speicher kann neukonfiguriert werden, um gemeinsam genutzt zu werden, gemeinsam genutzter Speicher kann neukonfiguriert werden, um privat zu sein, und Speicher, der für eine Partition privat ist, kann neukonfiguriert werden, um für eine weitere Partition privat zu sein. Speicher, der privat oder gemeinsam genutzt ist, kann ebenso neukonfiguriert werden, um nicht zugehörig zu sein. Die Speicherneukonfiguration kann das Hardware-In-Swapping oder das -Out-Swapping unterstützen. Befindet sich der Speicher in einem "nicht zugehörigen" Zustand in einem Konfigurationsbaum, kann er zu einem privaten Speicher einer Instanz oder als Teil des gemeinsam genutzten Speichers in einer Gemeinschaft neukonfiguriert werden. Wird der Speicher einem In-Swapping in ein System unterzogen, wird der Speicher zunächst in den nicht zugehörigen Zustand versetzt. Bevor der Speicher einem Out-Swapping aus einem System unterzogen werden kann, muss er sich darüber hinaus in einem nicht zugehörigen Zustand befinden. Um das Speicher-Hot-Swapping zu unterstützen, müssen somit die Betriebssystem-Instanz und die Konsolen-Software den Speicher in den und aus dem nicht zugehörigen Zustand neukonfigurieren. Wird der Speicher neukonfiguriert, wird der Seitenbereich beispielsweise zu 8 Megabyte (MB) angepasst (die Systemseitenzahl im Quadrat, geteilt durch 8 Bytes). Der Bereich der Seiten ist ein Vielfaches von 8 MB in der Größe, und wenn Seiten innerhalb des Bereiches, der aus dem System neukonfiguriert werden soll, in Verwendung sind, können andere Einschränkungen angewendet werden, wie es im folgenden beschrieben ist.
Neuer Speicher kann dem System zu einem beliebigen Zeitpunkt hinzugefügt werden, da die PFN-Datenbank derart bemessen ist, dass sie sämtlichen möglichen Speicher enthalten kann, der einem In-Swapping unterzogen werden kann, wobei die neuen Seiten immer verwendet werden können, um die PFN-Datenbankeintragsseiten auszumachen. Um Speicher aus einem System zu entfernen, wird zunächst ermittelt, ob der Bereich der Seiten privat, gemeinsam genutzt oder nicht zugehörig ist. Ist der Speicher bereits als nicht zugehörig markiert, wird er als entfernt betrachtet.
Für das Entfernen des privaten Speichers wird eine Liste entfernter Seiten von Seitenrahmenzahlen ähnlich einer Liste freier Seiten eingerichtet, um das Entfernen von Speicher zu unterstützen. Wird zu einem beliebigen Zeitpunkt bestimmt, dass die Seiten nicht online entfernt werden können, kann das System abgeschaltet werden, können die Seiten mit der Konsolen-Software als nicht zugehörig konfiguriert werden und kann die Betriebssystem-Instanz neugestartet werden. Verwendet die Konsole einige oder sämtliche der Seiten im Bereich, verlagert sich die Konsole selbst zu einem anderen Seitensatz. Diese Verlagerung kann auf vielfältige Art und Weise erreicht werden. Beispielsweise kann die Konsole ihre Seiten zu einer weiteren Art von Seiten kopieren, die der Partition zugehörig sind, und anschließend die Ausführung auf den anderen Seitensätzen beginnen. Alternativ kann eine weitere Konsole innerhalb einer weiteren Partition die Partition auflösen, den Bereich der Seiten als "nicht zugehörig" neuzuweisen und anschließend die Partition ohne den Speicher neubilden. Darüber hinaus kann das gesamte System abgeschaltet, der Speicher entfernt und das System neugestartet werden. Der Entfernvorgang kann zu jeder Zeit abgebrochen werden, indem die Seiten von der Liste entfernter Seiten zu den Listen der freien, genullten oder fehlerhaften Seiten bewegt werden.
Befindet sich der Bereich von Seiten, die zu entfernen sind, im privaten Speicher, werden die folgenden Schritte wiederholt, bis sämtliche Seiten entfernt werden können, oder der Entfernvorgang wird abgebrochen. Dieser Vorgang ist im Flussdiagramm von 19 dargestellt. Bevor in den Vorgang eingetreten wird, der im Flussdiagramm von 19 gezeigt ist, wird bestimmt, ob es ausreichenden Speicher gibt, um das Entfernen des Speichers zuzulassen. Ein Systemparameter, wie etwa eine Fließseitenzahl, wird normalerweise verwendet um zu kennzeichnen, dass die Zahl von freiem Speicher bereits verfügbar ist. Ist diese Fließseitenzahl zu gering, d. h. gibt es zu wenige Fleißseiten im System, um das Entfernen einzurichten, wird ein Fehler zum Benutzer zurückgesendet und andernfalls jede Seite im Bereich, der zu entfernen ist, untersucht, wie es in den Schritten beschrieben ist, die in 19 dargestellt sind.
Der Vorgang beginnt bei Schritt 1900 und schreitet von dort zu Schritt 1902 fort, bei dem die erste nicht entfernte Seite innerhalb eines zu entfernenden Seitenbereiches lokalisiert wird. Von Schritt 1902 schreitet der Vorgang zu Schritt 1904 fort, bei dem bestimmt wird, ob die Seite oder die Seiten, die zu entfernen sind, ausstehende Eingangs-/Ausgangs-Vorgänge haben und diese Seiten übersprungen werden; sobald ihre I/O-Vorgänge abgeschlossen sind, können die Seiten für das Entfernen erneut berücksichtigt werden. Haben die Seiten ausstehenden I/O, kehrt der Vorgang zu Schritt 1902 zurück, bei dem die erste nicht entfernte Seite lokalisiert wird, und von dort zu Schritt 1904, wie es zuvor beschrieben wurde. Um es dem System zu gestatten, andere Arbeit durchzuführen, kann es sein, dass das System an diesem Punkt stehen bleibt und darauf wartet, I/O abzuschließen.
Steht bei der momentanen nicht entfernten Seite kein I/O aus, schreitet der Vorgang von Schritt 1904 zu Schritt 1906 fort, bei dem bestimmt wird, ob sich die Seite auf der Liste der freien, genullten, ungeprüften oder fehlerhaften Seiten befindet. Befindet sich eine der Speicherseiten auf einer dieser Listen, wird die Seite von der Liste in Schritt 1908 entfernt und auf der Liste entfernter Seiten angeordnet. Freie Seiten werden zuerst behandelt, so dass kopierte Seiten nicht auf freie Seiten kopiert werden, die ebenfalls Teil des neukonfigurierten Bereiches sind. Von Schritt 1908 schreitet der Vorgang zu Schritt 1926 fort, bei dem bestimmt wird, ob sämtliche Seiten auf der Liste entfernter Seiten plaziert wurden, und wenn dies der Fall ist, schreitet der Vorgang fort, um in Schritt 1928 zu enden. Wenn andererseits sämtliche Seiten nicht auf der Liste entfernter Seiten plaziert wurden, kehrt der Vorgang zu Schritt 1902 zurück und fährt von dort fort, wie es zuvor beschrieben wurde. Sofern dies erwünscht ist, kann es eine Implementierung wählen, die Zahl von Iterationen zu begrenzen und einen Fehlerwiederherstellungsmechanismus ausführen, um einen immerwährenden Kreislauf zu vermeiden.
Gibt es keine Seiten in der Listen der freien, genullten und ungeprüften Seiten, schreitet der Vorgang von Schritt 1906 zu Schritt 1910 fort, bei dem bestimmt wird, ob es Seiten auf der Liste modifizierter Seiten gibt. Gibt es keine Seiten auf der Liste modifizierter Seiten, schreitet der Vorgang zu Schritt 1914 fort. Gibt es andererseits Seiten auf der Liste modifizierter Seiten, schreitet der Vorgang zu Schritt 1912 fort, bei dem die Seiten in einen Sicherungsspeicher, wie etwa eine Systemseitendatei, geschrieben werden. Von Schritt 1912 schreitet der Vorgang zu Schritt 1926 und von dort fort, wie es oben beschrieben wurde. Wenn andererseits der Vorgang von Schritt 1910 zu Schritt 1914 fortgeschritten ist, wird in Schritt 1914 bestimmt, ob beliebige Seiten Vorgangsseiten sind, d. h. Seiten, auf denen eine Applikation läuft. Da jeder Vorgang mehrere Threads haben kann, hat jeder Vorgang seine eigene Tabelle neben anderen Vorgängen. Sind beliebige Seiten Vorgangsseiten wird eine AST, die einen Mechanismus zur Ausführung innerhalb des Vorgangskontextes bereitstellt, um Zugriff auf die Vorgangseitentabellen zu erhalten, zum Vorgang gesendet, wobei die AST den Vorgang als einzelnen Thread einstellt, sofern dies erforderlich ist, um den Zugriff auf die Tabellenseiten zu synchronisieren. Neue Seitenrahmenzahlen werden für die Seiten zugeordnet und die Inhalte der Seiten zu den neuen Seitenrahmenzahlen kopiert. Die alten Seitenrahmenzahlen werden in Schritt 916 in der Liste entfernter Seiten der Instanz plaziert. Von Schritt 916 schreitet der Vorgang zu Schritt 1926 fort und von dort, wie es zuvor beschrieben wurde.
Wird in Schritt 1914 bestimmt, dass keine der Seiten Vorgangsseiten sind, schreitet der Vorgang zu Schritt 1918 fort, bei dem bestimmt wird, ob beliebige der Seiten Teil eines globalen Abschnittes sind, d. h. ein Satz von privaten Seiten, auf die durch zahlreiche Vorgänge gleichzeitig zugegriffen wird. Sind beliebige der Seiten Teil des globalen Abschnittes, schreitet der Vorgang von Schritt 1918 zu Schritt 1920 fort. In Schritt 1920 kann der Name des globalen Abschnittes einem Benutzer angezeigt werden, so dass ein Benutzer bestimmen kann, welche Applikation abgeschaltet werden muss, um Speicher zu löschen. Alternativ kann ein Betriebssystem, das verfolgen kann, wo Seiten abgebildet werden, sämtliche Vorgänge aussetzen, die auf den Abschnitt abgebildet werden, sämtliche Seiten kopieren, sämtliche Vorgangsseiten-Tabelleneinträge modifizieren und die alten Seitenrahmenzahlen auf der Liste entfernter Seiten anordnen. Von Schritt 1920 würde der Vorgang anschließend zu Schritt 1926 und von dort fortschreiten, wie es zuvor beschrieben wurde. Wenn in Schritt 1918 bestimmt wird, dass es keine Seiten gibt, die Teil des globalen Abschnittes sind, schreitet der Vorgang zu Schritt 1922 fort, bei dem bestimmt wird, ob eine beliebige Seite in den Systemadressraum abgebildet wird. Wird keine Seite in den Systemadressraum abgebildet, schreitet der Vorgang von Schritt 1922 zu Schritt 1926 und von dort fort, wie es zuvor beschrieben wurde.
Werden andererseits Seiten in den Systemadressraum abgebildet, schreitet der Vorgang zu Schritt 1924 fort, bei dem jene Seiten, die lediglich gelesen werden, kopiert werden. Sobald sie kopiert ist, wird die Seite in der Liste entfernter Seiten plaziert. Lese-/Schreibseiten werden nur dann kopiert, während sämtliche CPUs innerhalb der Instanz vorübergehend an der Ausführung blockiert sind, so dass sie nicht die Inhalte der Seite ändern. Es wird eine Seite nach der anderen kopiert, und es werden die kopierten Seiten in der Liste entfernter Seiten plaziert. Nach der Migration in Schritt 1924 schreitet der Vorgang zu Schritt 1926 und von dort fort, wie es zuvor beschrieben wurde.
Um gemeinsam genutzten Speicher zu entfernen, wird eine neue Liste von Seitenrahmenzahlen innerhalb jeder Gemeineigenschafts-Partitionsdatenstruktur gemeinsam genutzten Speichers eingerichtet, d. h. innerhalb jeder SHM-CPP-Struktur innerhalb der APMP-Datenbank. Die Liste wird Liste entfernter Seiten der Gemeineigenschafts-Partition genannt. Diese Listen halten vorübergehend Plätze für sämtliche Seiten, die entfernt werden können. Nur wenn sämtliche Seiten innerhalb des 8-MB-Bereiches in der geeigneten Liste entfernter Seiten lokalisiert sind, können die Seiten entfernt werden. Wird bestimmt, dass die Seiten nicht entfernt werden können, während der gemeinsam nutzende Satz (der Satz von Instanzen, die Ressourcen, wie etwa Speicher, gemeinsam nutzen) in Betrieb ist, kann zu einem beliebigen Zeitpunkt die gemeinsame Nutzung aufgelöst werden, können die Seiten als nicht zugehörig markiert werden, und kann der gemeinsam nutzende Satz neu gebildet werden. Der Entfernvorgang kann zu einem beliebigen Zeitpunkt abgebrochen werden, indem die Seiten von der Liste entfernter Seiten der Gemeineigenschafts-Partition zur Liste freier Seiten oder fehlerhafter Seiten in Abhängigkeit des vorherigen Zustandes bewegt werden, d. h. zur Liste freier Seiten, sofern sie sich auf der Liste freier Seiten befand, und zur Liste fehlerhafter Seiten, sofern sie sich auf der Liste fehlerhafter Seiten befand.
Der Vorgang des Entfernens gemeinsam genutzten Speichers ist im Flussdiagramm von 20 dargestellt, wobei der Vorgang bei Schritt 2000 beginnt und von dort zu Schritt 2002 fortschreitet, wodurch die erste nicht entfernte Seite im Bereich von Seiten, die entfernt werden sollen, lokalisiert wird. Von Schritt 2002 schreitet der Vorgang zu Schritt 2004 fort, bei dem bestimmt wird, ob beliebige Seiten innerhalb des Bereiches von Seiten, die entfernt werden sollen einen ausstehenden I/O haben. Jene Seiten, die einen ausstehenden I/O haben, werden übersprungen, und der Vorgang kehrt zu Schritt 2002 zurück, um die erste nicht entfernte Seite zu lokalisieren, wie es zuvor beschrieben wurde. Um es dem System zu gestatten, andere Arbeit auszuführen, kann es sein, dass ein System an diesem Punkt stehen bleiben möchte, um auf die Fertigstellung von I/O zu warten.
Haben keine Seiten einen ausstehenden I/O, schreitet der Vorgang von Schritt 2004 zu Schritt 2006 fort, bei dem bestimmt wird, ob beliebige Seiten Teil der APMP-Datenbank sind. Sind beliebige der Seiten Teil der APMP-Datenbank, wird an den Benutzer ein Fehler in Schritt 2008 zurückgesendet. In einem derartigen Fall muss der gemeinsam nutzende Satz mit der APMP-Datenbank auf unterschiedlichen Seiten neu gebildet werden. Dies kann bewerkstelligt werden, indem der gemeinsam nutzende Satz aufgelöst wird, die alten APMP-Datenbankseiten als nicht zugehörig markiert werden, ein neuer Satz von APMP-Datenbankseiten gewählt wird und anschließend der gemeinsam nutzende Satz neu geschaffen wird. Der Vorgang schreitet von Schritt 2008 fort, um in Schritt 2030 zu enden.
Die Zuordnung der Seitenrahmenzahl-Datenbankeintragsseiten, die diese Seiten beschreiben, werden aufgehoben und für die Liste freier Seiten der Gemeineigenschafts-Partition freigegeben, die PMAP-Anordnungen, die gemeinsam genutzten Speicher beschreiben, werden aktualisiert, um die Änderung widerzuspiegeln und die Konsole wird aufgerufen, um die Seite als nicht zugehörig zu markieren. Von Schritt 2028 schreitet der Vorgang anschließend fort, um in Schritt 2030 zu enden. Wenn in Schritt 2026 der Vorgang bestimmt hatte, dass sich sämtliche Seiten nicht auf der Liste entfernter Seiten des gemeinsam genutzten Speichers der Gemeineigenschafts-Partition befanden, kehrt der Vorgang von Schritt 2026 zu Schritt 2002 zurück und schreitet von dort fort, wie es zuvor beschrieben wurde. Wenn in Schritt 2006 der Vorgang bestimmt, dass keine der Seiten Teil der APMP-Datenbank ist, schreitet der Vorgang zu Schritt 2010 fort, bei dem bestimmt wird, ob sich beliebige der Seiten auf der Liste freier, fehlerhafter oder nicht geprüfter Seiten befinden, und wenn dies der Fall ist, werden die Seiten entfernt und in der Liste entfernter Seiten der Gemeineigenschafts-Partition 2012 plaziert. Von Schritt 2012 schreitet der Vorgang zu Schritt 2026, und von dort, fort, wie es zuvor beschrieben wurde.
Wenn in Schritt 2010 bestimmt wird, dass sich keine der Seiten auf der Liste freier, fehlerhafter oder nicht geprüfter Seiten befindet, schreitet der Vorgang zu Schritt 2014 fort, bei dem bestimmt wird, ob beliebige Seiten Seitenrahmenzahl-Datenbankseiten des gemeinsam genutzten Speichers sind, und wenn dies der Fall ist, schreitet der Vorgang zu Schritt 2016 fort. Vorausgesetzt der Bereich der Seiten enthält nur die Seiten, die innerhalb der Gemeineigenschafts-Partition des gemeinsam genutzten Speichers übrig sind und die sich nicht auf der Liste entfernter Seiten der Gemeineigenschafts-Partition befinden, wird in Schritt 2016 die Gemeineigenschafts-Partition aus der Gemeinschaft entfernt. In Schritt 2016 wird die Gemeineigenschafts-Partition des gemeinsam genutzten Speichers als ungültig markiert, so dass keine Versuche unternommen werden, Seiten von dieser zuzuordnen. Die PMAP-Anordnungen, die gemeinsam genutzten Speicher beschreiben, werden aktualisiert, um das Entfernen des Speichers widerzuspiegeln. Andere APMP-Datenbankstrukturen gemeinsam genutzten Speichers werden aktualisiert, um das Entfernen der Gemeineigenschafts-Partition des gemeinsam genutzten Speichers widerzuspiegeln, wobei die Konsole aufgerufen wird, um die Seiten als nicht zugehörig zu markieren. Wenn die PFN-Datenbankseiten nicht die einzigen Seiten sind, die in der Gemeineigenschafts-Partition gemeinsam genutzten Speichers zurückbleiben, die sich nicht auf der Liste entfernter Seiten befinden, kann alternativ ein Fehler an den Benutzer zurückgegeben werden, wobei in diesem Fall der Benutzer den gemeinsam nutzenden Teil auflösen, die Seiten als nicht zugehörig markieren und den gemeinsam nutzenden Satz neu erzeugen könnte. Um diese Seiten zu kopieren, könnte die Gemeineigenschafts-Partition des gemeinsam genutzten Speichers, die die Seiten enthält, als vorübergehend ungültig markiert werden und die Abbildung der PFN-Datenbankseiten als nur lesen markiert werden. Eine Instanz könnte anschließend die Seiten zu einem neuen Satz von Seiten kopieren, die von der Gemeineigenschafts-Partition zugeordnet werden. Sämtliche Instanzen würden anschließend ihre Abbildungen von der alten Seite zu den neuen Seiten abändern, worauf die alten Seiten anschließend auf der Liste entfernter Seiten der Gemeineigenschafts-Partition plaziert werden könnten. Der Vorgang würde anschließend von Schritt 2016 zu Schritt 2026 und von dort so fortschreiten, wie es zuvor beschrieben wurde.
Wenn in Schritt 2014 bestimmt wird, dass einige Seiten nicht Seitenrahmenzahl-Datenbankseiten des gemeinsam genutzten Speichers sind, würde der Vorgang zu Schritt 2018 fortschreiten, bei dem bestimmt wird, ob beliebige der Seiten Teil eines Bereiches gemeinsam genutzten Speichers sind, der in den Systemraum abgebildet wird, und wenn dies der Fall ist, würde der Vorgang zu Schritt 2020 fortschreiten, bei dem Rückrufroutinen gemeinsam genutzten Speichers aufgerufen und den benutzten Speicher zurückhalten würden, der entfernt werden soll. Die Rückrufroutinen können entweder die Applikation beenden oder einen neuen Bereich gemeinsam genutzten Speichers erzeugen und beginnen, den neuen Bereich zu verwenden. Alternativ oder in Verbindung mit den Rückrufroutinen kann das Etikett des Bereiches gemeinsam genutzten Speichers durch die Konsole angezeigt werden. Dies würde es dem Benutzer gestatten, das Herunterfahren der Applikation zu unterstützen, die den gemeinsam genutzten Speicher verwendet. Von Schritt 2020 würde der Vorgang anschließend zu Schritt 2026 und von dort derart fortschreiten, wie es zuvor beschrieben wurde.
Wenn in Schritt 2018 bestimmt wird, dass keine der Seiten Teil eines Bereiches gemeinsam genutzten Speichers sind, der in den Systemraum abgebildet wird, schreitet der Vorgang zu Schritt 2022 fort, bei dem bestimmt wird, ob beliebige Seiten Teil eines globalen Abschnittes gemeinsam genutzten Speichers sind, d. h. eines Satzes von Abbildungen gemeinsam genutzter Seiten in einen oder mehrere Adressräume eines Vorgangs, so dass sämtliche Vorgänge Zugriff auf dieselben Seiten haben können. Gibt es einige Seiten, die Teil eines globalen Abschnittes gemeinsam genutzten Speicher sind, schreitet der Vorgang zu Schritt 2024 fort, bei dem eine Rückrufroutine an allen Instanzen aufgerufen wird, deren globaler Abschnitt abgebildet ist. Sämtliche Vorgänge, die auf den globalen Abschnitt abgebildet werden, können ausgesetzt werden, worauf der Code dann sämtliche Daten von einem Seitensatz zu einem weiteren kopieren, sämtliche Vorgangsseiten-Tabelleneinträge abändern, die Datenstrukturen des globalen Abschnittes abändern und die alten Seitenrahmenzahlen in die Liste entfernter Seiten der Gemeineigenschafts-Partition plazieren kann. Alternativ kann jeder Vorgang, der auf den globalen Abschnitt abbildet, benachrichtigt oder abgeschaltet werden, oder es können die Namen der globalen Abschnitte angezeigt werden, so dass der Benutzer bestimmen kann, welche Applikation abgeschaltet werden sollte, um den Entfernvorgang zu unterstützen. Von Schritt 2024 würde der Vorgang anschließend zu Schritt 2026 und von dort derart fortschreiten, wie es zuvor beschrieben wurde.
Um sicherzustellen, dass, wenn I/O für gemeinsam genutzten Speicher initiiert wurde, der Speicher nicht für einen anderen Zweck verwendet wird, bevor wir davon ausgehen können, dass der vollständige I/O im gemeinsam genutzten Speicher abgeschlossen ist, kann eine I/O-Vorrichtung die Instanz unterbrechen, wenn I/O abgeschlossen ist, worauf das System aufzeichnen würde, dass der I/O abgeschlossen ist. Wenn alternativ sämtliche I/O-Busse innerhalb der Partition der Instanz rückgesetzt wurden, ist I/O abgeschlossen. In der SHM_DESC-Struktur im privaten Speicher befindet sich ein Feld mit dem Namen I/O refcnt, das für die I/O-Bezugszahl steht. Es gibt eine SHM_DESC-Struktur je gemeinsam genutztem Speicherbereich.
In der SHM_REG-Struktur in der APMP-Datenbank gibt es eine Bitmaske, die "angefügte Bitmaske" genannt wird. Es gibt lediglich eine SHM_REG-Struktur je gemeinsam genutztem Speicherbereich. Die angefügte Bitmaske enthält ein Bit für jede Instanz im APMP-System. Wenn ein Bit in der angefügten Bitmaske eingestellt ist, wird die entsprechende Instanz an diesem Bereich angefügt.
In der Konfigurationsbaumstruktur, die von der Konsole gewartet wird, gibt es ein ID-Feld im Partitionsknoten, das eingestellt oder gelöscht werden kann, indem eine Konsolen-Rückrufroutine aufgerufen wird. Während des Systemstarts wird nachdem die Partitions-I/O-Busse rückgesetzt wurden, dieses Feld im Partitionsknoten der Instanz gelöscht.
Wenn ein Satz gemeinsamer Nutzung erzeugt wird:

1) Führe einen Kreislauf durch alle anderen Partitionsknoten der Instanz in dieser Gemeinschaft aus.
2) Setze, wenn das ID-Feld nicht Null ist und es keine Instanz gibt, die auf der Partition läuft, wie es innerhalb des Konfigurationsbaumes gekennzeichnet ist, sämtliche I/O-Busse zurück, die mit der Partition verbunden sind.
3) Setze das ID-Feld in diesem Partitionsknoten der Instanz auf die ID (eine Zahl, die immer dann zunimmt, wenn die APMP-Datenbank neu erzeugt wird).

Wenn eine Instanz einem gemeinsam nutzenden Satz beitritt:

1) Stelle das ID-Feld im Partitionsknoten der Instanz auf die momentane ID.

Während des Ausstiegs eines gemeinsam nutzenden Satzes:

1) Rufe eine Routine auf, die eine Ablösung von sämtlichen gemeinsam genutzten Speicherbereichen ausführt.
2) Lösche das ID-Feld im Partitionsknoten der Instanz im Konfigurationsbaum.

Wird ein I/O initiiert, wird die Routine shm_reg_incref für jede Seite aufgerufen, auf der I/O ausgeführt wird. Ist I/O abgeschlossen, wird die Routine shm_reg_decref für jede Seite aufgerufen.
Routine shm_reg_incref:

Eingabe: Adresse des PFN-Datenbankeintrags für die Seite
Lesen der ID des gemeinsam genutzten Speicherbereiches aus dem PFN-Datenbankeintrag.
Beziehen der SHM_DESC-Adresse im privaten Speicher für diese Bereich.
Erhöhen von I/O refcnt.

Routine shm_reg_decref:

Eingabe: Adresse des PFN-Datenbankeintrags für die Seite
Lesen der ID des gemeinsam genutzten Speicherbereiches aus dem PFN-Datenbankeintrag.
Beziehen der SHM_DESC-Adresse im privaten Speicher für diesen Bereich.
Verringern von I/O refcnt

Routine shm_reg_create:

Eingaben: Etikett
virtuelle Länge
physikalische Länge
virtuelle Abbildungsinformationen
plus zusätzliche Informationen
Ausgabe: ID des gemeinsam genutzten Speicherbereiches
Suche nach SHM_REG-Struktur im gemeinsam genutzten Speicher, dessen Etikett mit dem zugeführten Etikett übereinstimmt.
Wird keine derartige SHM_REG-Struktur gefunden:

– Zuordnen einer neuen SHM_REG-Struktur
– Beziehen der SHM_REG-Verriegelung
– Einstellen des "Initialisierungsfortschritts"-Bits in der SHM_REG-Struktur
– Löschen des "Initialisierungsfortschritts"-Bits in der SHM_REG-Struktur
– Freigeben der SHM_REG-Verriegelung

Einstellen des Bits in der an SHM_REG angefügten Bitmaske für diese Instanz
Abbilden des gemeinsam genutzten Speicherbereiches mit Hilfe der zugeführten Informationen für virtuelle Abbildung.

Routine shm_reg_delete:

Eingabe: ID des gemeinsam genutzten Speicherbereiches
Beziehen der SHM_DESC-Adresse im privaten Speicher für diesen Bereich.
Ist das I/O-refcnt-Feld nicht Null, Rücksenden eines Fehlers
Beziehen einer SHM_REG-Adresse im gemeinsam genutzten Speicher für diesen Bereich.
Löschen des Bits in der an SHM_REG angefügten Bitmaske für diese Instanz.
Sind bei der angefügten Bitmaske zusätzliche Bits eingestellt, Rückkehr.
Sind in der an SHM_REG angefügten Bitmaske keine Bits eingestellt:

– Beziehen der SHM_REG-Verriegelung
– Einstellen des "Löschfortschritts"-Bits in der SHM_REG-Struktur
– Aufheben der Zuordnung sämtlicher Seiten gemeinsam genutzten Speichers für die geeigneten Listen freier Seiten des gemeinsam genutzten Speichers.
– Löschen des "Löschfortschritts"-Bits
– Freigeben der SHM_REG-Verriegelung
– Bereinigen der SHM_REG-Datenstruktur

Während des Systemabsturzes:
Rücksetzen sämtlicher I/O-Busse.
Löschen des ID-Feldes im Partitionsknoten der Instanz.
Aufrufen des Systemcodes, um eine weitere Instanz zu unterbrechen und so anzuzeigen, dass die Instanz abgestürzt ist. (Die Interrupt-Handhabungseinrichtung auf der anderen Instanz ruft shmem_APMPDB_recover auf.)
Initiieren der Absturzauflistung
Während der Heartbeat-Überwachung: Wenn das Herz einer Instanz für einen Zeitraum nicht schlägt, wird die Instanz als tot erklärt und aus dem gemeinsam nutzenden Satz gelöscht.
Beziehen der SHM_REG-Synchronisationsverriegelung, Aufheben der Verriegelung sofern notwendig. Wenn die Verriegelung von der toten Instanz gehalten wurde: Wenn die SHM_REG-Struktur anzeigt, dass die Initialisierung im Fortschritt war, oder dieser Bereich im Begriff war, gelöscht zu werden, Aufrufen von shm_reg_delete.
Die Routine shmem-APMPDM_recover wird auf wenigstens einer der anderen Instanzen aufgerufen. In diesem Fall wird das ID_Feld des Partitionsknotens in der Instanz nicht gelöscht.

Routine shmem_APMPDB_recover:

Eingabe: Instanz-ID des toten Knotens
Kreislauf durch sämtliche SHM_REG-Strukturen in der APMP-Datenbank.
War die abstürzende Instanz am Bereich angebracht:

1) Ist das ID-Feld des Partitionsknotens der Instanz nicht Null, kann dies kennzeichnen, das die Instanz angehalten war und nicht abgestürzt ist. I/O-Vorrichtungen können weiterhin in den gemeinsam genutzten Speicher schreiben. Kreislauf zur nächsten SHM_REG-Struktur, wobei diese Instanz angefügt und der gemeinsam genutzte Speicherbereich an Ort und Stelle bleibt. Wenn die Instanz wieder dem gemeinsam nutzenden Satz beitritt, löscht sie das angefügte Bit, nachdem sie die I/O-Busse zurückgesetzt hat. Sie löscht den gemeinsam genutzten Speicherbereich, wenn sie die letzte Instanz war, die am Bereich angefügt war.
2) Wenn das ID-Feld des Partitionsknotens der Instanz gelöscht ist: Löschen des Bits für die Instanz in der angefügten Bitmaske
Sind in der angefügten Bitmaske keine Bits eingestellt: Aufrufen von shm_reg_delete
Kreislauf zur nächsten SHM_REG-Struktur
Nachdem sämtliche SHM_REG-Strukturen verarbeitet worden sind,
Ausführen eines größeren Teils des Wiederherstellungscodes des gemeinsam genutzten Speichers.

Routine shmem_sharing_set_join:

Eingabe: Instanz-ID dieser Instanz.
Abbilden auf die APMP-Datenbank im gemeinsam genutzten Speicher.
Ausführen anderen Gemeinschafts-Teilnahmecodes des gemeinsam genutzten Speichers.
Kreislauf durch alle SHM_REG-Strukturen in der APMP-Datenbank.
War diese Instanz am Bereich angebracht:

– Löschen des Bits für diese Instanz in der angefügten Bitmaske

Sind in der angefügten Bitmaske keine weiteren Bits eingestellt

– Aufrufen von shm_reg_delete

Kreislauf zur nächsten SHM_REG-Struktur
Nachdem sämtliche SHM_REG-Strukturen verarbeitet wurden, Rückkehr.
Um die anfänglichen APMP-Datenbankseiten zu wählen, wird die Routine
shmem_config_APMPDB von APMPDB_map_initial aufgerufen, um den Ausgangssatz von APMPDB-Seiten zu wählen.

Datenstrukturen:
Der Gemeinschaftsknoten im Konfigurationsbaum-Knoten enthält ein 64-Bit-Feld mit dem Namen APMPDB_INFO, das verwendet wird, um APMPDB-Informationen zu speichern. Die ersten 32 Bits APMPDB_INFO[31:0] sind die niedrige PFN der APMPDB-Seiten. Die zweiten 32 Bits APMPDB_INFO[63:32] sind die Seitenzahl der APMPDB-Seiten.
Jede Instanz hält eine Anordnung im privaten Speicher mit dem Namen "Anordnung des gemeinsam genutzten Speichers". Jedes Element in der Anordnung enthält eine PFN gemeinsam genutzten Speichers und eine Seitenzahl. Die gesamte Anordnung beschreibt den gesamten Speicher, der der Gemeinschaft zugehörig ist, zu der die Instanz gehört.
Der Konfigurationsbaum kann geprüfte Speicher-Bitabbildungen für gemeinsam genutzten Speicher beinhalten. Enthält der Konfigurationsbaum eine Bitabbildung für einen Speicherbereich, ist der Speicher geprüft und in Ordnung. Existiert eine Bitabbildung für einen Speicherbereich, zeigt jedes Bit in der Bitabbildung an, ob eine Seite gemeinsam genutzten Speichers gut oder schlecht ist.
Ein Wert MAX_APMPDB_PAGES wird auf die Maximalzahl der Seiten eingestellt, die erforderlich sind, um das System zu initialisieren. Diese Zahl sollte kleiner sein als die Granularität des gemeinsam genutzten Speichers.
MAX_APMPDB_PAGES sollte eine kleine Zahl sein, um die Chancen zu erhöhen, das zusammenhängender, fehlerfreier Speicher für die Initialisierung der APMP-Datenbank gefunden werden kann. Konsolen-Rückrufroutine set_APMPDB_info:
Diese Routine kann komplexer sein, wenn mehrere Kopien des Konfigurationsbaumes von einer Konsole beibehalten werden.

1. Lesen von APMPDB_INFO aus dem Gemeinschaftsknoten
2. Ist APMPDB_INFO nicht gleich old_APMPDB_info, Rücksenden eines Fehlers
3. Speichern von new_APMPDB_INFO in APMPDB_INFO mit einer atomischen Anweisung

Eine Routine SHMEM_config_APMPDB wird verwendet, um die APMP-Datenbank zu konfigurieren. Die Routine stellt die erste APMP-Datenbank-Seitenrahmenzahl und die Zahl von Seiten bereit, die für die APMP-Datenbank festgelegt sind. Die Routine schreitet wie folgt fort:

(1) Beziehen eines Verweises für den Gemeinschaftsknoten innerhalb, des Konfigurationsbaumes
(2) Durchqueren des Konfigurationsbaumes, wobei eine Anordnung gemeinsam genutzten Speichers erzeugt wird. Gibt es keinen gemeinsam genutzten Speicher, Rücksenden eines Fehlers.
(3) Lesen des APMPDB_INFO-Feldes
(4) Ist das APMPDB_INFO-Feld nicht Null Einstellen von PAGES auf APMPDB_INFO Absuchen der Anordnung gemeinsam genutzten Speichers, um sicherzustellen, das sich die Seiten PFN bis PFN+PAGES-1 im gemeinsam genutzten Speicher befinden Befinden sich diese Seiten in der Anordnung gemeinsam genutzten Speichers: Sofern eine geprüfte Speicher-Bitabbildung existiert, Prüfen der Bitabbildung um sicherzustellen, dass diese Seiten nicht als fehlerhaft markiert sind Sind sämtliche Seiten fehlerfrei, Aufrufen von set_APMPDB_INFO, um PFN und PAGES in das APMPDB_INFO-Feld zu schreiben Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, sende PFN und PAGES zum Anrufer zurück Befinden sich beliebige der Seiten nicht im gemeinsam genutzten Speicher oder sind diese fehlerhaft Aufrufen von SET_APMPDB_INFO, um das APMPDB_INFO-Feld zu löschen Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, gehe zu (5), um die APMPDB-Seiten zu wählen
(5) Einstellen von PAGES auf MAX_APMPDB_PAGES
(6) Kreislauf durch die Anordnung gemeinsam genutzten Speichers. Für jedes Element in der Anordnung:
(6.1) Einstellen von PFN auf die niedrigste PFN des gemeinsam Genutzten Speichers im Bereich.
(6.2) Ist eine geprüfte Bitabbildung vorhanden, Prüfen der Bitabbildung um sicherzustellen, dass diese Seiten nicht als fehlerhaft markiert sind
(6.3) Sind sämtliche Seiten fehlerfrei Aufrufen von SET_APMPDB_INFO, um PFN-Seiten in das APMPDB-Feld zu schreiben Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, sende PFN und PAGES zum Anrufer zurück
(6.4) Werden fehlerhafte Seiten innerhalb des Bereiches angetroffen Stelle PFN auf die höchst numerierte fehlerhafte PFN+1 ein Befindet sich PFN+PAGES-1 weiterhin innerhalb des Anordnungselementes des gemeinsam genutzten Speichers, Rückkehr zu (6.2) Ist PFN+PAGES-1 größer als der Bereich, der von diesem Anordnungselement des gemeinsam genutzten Speichers beschrieben ist, Bewegen zum nächsten Anordnungselement des gemeinsam genutzten Speichers
(6.5) Sind keine Anordnungselemente des gemeinsam genutzten Speichers übrig, Rücksenden eines Fehlers.

Eine beispielhafte Seitenrahmenzahl-Datenbankanordnung ist durch die Speicherabbildung in 21 dargestellt. Bei diesem Beispiel enthält das System zwei Instanzen A und B, jeweils mit 64 Megabyte privaten Speichers und 64 Megabyte gemeinsam genutzten Speichers. Der Speicher ist als 8-kB-Seiten angeordnet, wobei sich der private Speicher für die Instanz A von der Seitenrahmenzahl (PFN) 0 durch PFN 1BFF (hexadezimal) erstreckt. 64 MB gemeinsam genutzten Speichers erstrecken sich von PFN 2000- zu PFN 3FFF. Der private Speicher für die Instanz B erstreckt sich von PFN 800000 durch PFN 801FFF. Der Speicher, der verwendet wird, um die PFN-Datenbank für Instanz A zu halten, kommt aus dem privaten Speicher (0-1FFF) der Instanz A, der Speicher, der verwendet wird, um die PFN-Datenbank für Instanz B zu halten, kommt aus dem privaten Speicher (2000-3FFF) der Instanz B, und der Speicher, der verwendet wird, um die PFN-Datenbank für den gemeinsam genutzten Speicher zu halten, kommt aus dem gemeinsam genutzten Speicher (800000-801FFF). Die Instanz A kann nicht auf die PFN-Datenbankeinträge für den Speicher der Instanz B zugreifen, da, wie es dargestellt ist, dieser Speicherbereich nicht in den Systemraum für die Instanz A abgebildet wird. In ähnlicher Weise kann die Instanz B nicht auf die PFN-Datenbankeinträge für den Speicher der Instanz A zugreifen, da dieser Speicher bereich nicht in den Systemraum für die Instanz B abgebildet wird. Sowohl die Instanzen A und B bilden die gemeinsam genutzten Seiten in die PFN-Datenbankeinträge für den gemeinsam genutzten Speicher ab. Die Instanzen bilden auf die gemeinsam genutzten Seiten mit Privatspeicherseiten-Tabellen ab, weil PFN-Datenbankeinträge privaten Speichers und gemeinsam genutzten Speichers von denselben Seitentabellenseiten abgebildet werden können. Wie es oben erläutert wurde, kann die Granularität des physikalischen Speichers als das kleinste gemeinsame Vielfache einer PFN-Datenbankeintragsgröße und der Speicherseitengröße gewählt werden. Beim dargestellten Beispiel beträgt die Speicherseitengröße 8 kB, wobei die Granularität des physikalischen Speichers gleich der Seitengröße im Quadrat dividiert durch acht (Bytes) oder 8 MB ist. Die Seitengrößen von 16, 32 und 64 kB führen zu einer Granularität des physikalischen Speichers von 32, 128 bzw. 512 MB.
G. FEHLERWIEDERHERSTELLUNG IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (22–32)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebe ne Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardware-Grenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Bei der vorliegenden Erfindung enthalten die einzelnen Instanzen jeweils einen separaten Eintrag sämtlicher Verarbeitungsressourcen des Systems. Jede der Instanzen kategorisiert die Prozessoren auf der Basis ihres jeweiligen Betriebszustandes im Bezug auf die Instanz. Bei einer bevorzugten Ausführungsform enthält eine Instanz Einträge darüber, ob jede CPU kompatibel für den Betrieb mit der Instanz ist, ob sie von der Instanz gesteuert wird und ob sie für den SMP-Betrieb innerhalb der Instanz verfügbar ist. Diese unterschiedlichen Betriebszustände repräsentieren eine hierarchische Kategorisierung der CPUs des Systems, wobei das System auf zusätzliche Kategorien anpassbar ist.
Bei der bevorzugten Ausführungsform wird die Mitgliedschaft der CPUs in einer der unterschiedlichen Kategorien des Betriebszustandes von jeder Instanz aufgezeichnet, die Bitvektoren für jede Kategorie enthält, wobei wenigstens ein Bit jedes Bitvektors dem Mitgliedszustand einer der CPUs in dieser Kategorie entspricht. Normalerweise hat jeder Satz ein Bit für jede der CPUs, so dass beispielsweise ein Bitvektor, der für die CPU-Steuerung durch die in Frage kommende Instanz kennzeichnend ist, ein erstes Bit hat, das auf einen ersten Aussagegrad eingestellt ist, wenn eine erste entsprechende CPU von der Instanz gesteuert wird. Wird die CPU nicht von der Instanz gesteuert, ist das Bit auf einen zweiten Aussagegrad eingestellt. Mit einem Bit, das für jede der CPUs kennzeichnend ist, stellt dieser Bitvektor anschließend Kennzeichnungen für jede der CPUs bereit, die aussagen, welche sich unter Steuerung der Instanz befinden. In ähnlicher Weise stellen andere Bitvektoren Kennzeichnungen für jede der CPUs bereit, wobei diese Kennzeichnungen beispielsweise anzeigen, welche CPUs für den Betrieb mit der Instanz kompatibel sind und welche für die Instanz für den SMP-Betrieb verfügbar sind. Auf diese Weise kann jede der Instanzen individuell sämtliche Verarbeitungsressourcen und deren Betriebszustände relativ zur Instanz verfolgen.
Die Erfindung kann zudem eine Einrichtung zum automatischen Bewegen eines Prozessors von einer ersten Instanz zu einer zweiten Instanz in einer Instanz-Fehlersituation enthalten. Eine derartige Bewegung kann die Ausführung einer Anweisung durch den sich bewegenden Prozessor verwenden. Wird eine Bewegung initiiert, speichert der migrierende Prozessor seinen momentanen Betriebszustand und ist in der Lage, einen Hardware-Zustand zu laden, den er während einer vorherigen Ausführung innerhalb der zweiten Instanz innehatte. Somit nimmt der Prozessor den Betrieb in der zweiten Instanz dort wieder auf, wo er ihn zuvor verlassen hatte. Gibt es keinen gespeicherten Hardware-Zustand in der Instanz, zu der der Prozessor migriert, befindet er sich in einem initialisierten Zustand.
Bei einer bevorzugten Ausführungsform der Erfindung antwortet das System auf einen Fehler innerhalb einer ersten Instanz, indem es nicht nur das Betriebssystem herunterfährt, das auf dieser Instanz läuft, sondern zuerst Verarbeitungsressourcen aus der ersten Instanz zu Bestimmungsinstanzen migriert. Das heißt, die Steuerung für eine gegebene Ressource, die der ersten Instanz zugewiesen ist, wird auf eine zweite Instanz ohne Eingreifen einer Bedienperson übertragen. Das System kann eine Instanz haben, die keine Verarbeitungsaufgaben vor dem Fehlschlag der ersten Instanz hat, die jedoch als Sicherung für die erste Instanz dient. Jede CPU migriert zur Bestimmungsinstanz und übernimmt vorzugsweise dieselben Funktionen, die sie bei der ersten Instanz ausgeführt hatte. Jede Instanz speichert vorzugsweise die IDs der Bestimmungsinstanz in einer Anordnung, die nach CPU-ID organisiert ist. Bei Auftreten eines Fehlers innerhalb der ersten Instanz kann somit jeder Prozessor, der von der ersten Instanz gesteuert wird, auf sein zugehöriges Anordnungselement blicken, um die ID für die Instanz zu bestimmen, zu der er migrieren soll.
Die Migration der Prozessoren von der ersten Instanz nach einem Fehler, beinhaltet lediglich sekundäre Prozessoren. Der primäre Prozessor für diese Instanz stellt sicher, dass sämtliche sekundären Prozessoren selbst migrieren, oder dass eine separate Migrationsroutine aufgerufen wird, um beliebige Prozessoren zu migrieren, die nicht vollständig an SMP-Aktivitäten teilnehmen. Der primäre Prozessor speichert anschließend sämtliche Daten im Speicher, der von der ersten Instanz gesteuert wird, an einem neuen Speicherort, worauf er sich selbst abschaltet. Sobald die erste CPU der ersten Instanz abgeschaltet ist, erkennt das Konsolen-Programm diese Tatsache und stellt ein Kennzeichen im gemeinsam genutzten Speicher ein, das kennzeichnet, dass sich die erste CPU der ersten Instanz in der "Konsolenbetriebsart" befindet. Die Konsole sendet anschließend einen Interrupt zu jeder der anderen Instanzen im System, wodurch diese veranlasst werden, die Einstellung des Kennzeichens zu erkennen. In der Zwischenzeit wird die Verarbeitung in der Sicherungsinstanz wieder aufgenommen. In bestimmten Fällen können CPUs, die von einer Instanz migrieren, die eine Fehlfunktion erfahren hat, zu anderen Bestimmungsinstanzen migrieren. Das Zulassen unterschiedlicher Bestimmungsinstanzen für die unterschiedlichen Ressourcen ermöglicht eine Flexibilität bei der Neuverteilung der Ressourcen des Systems nach einem Fehler in einer der Instanzen.
Laufzeitmigration der Ressourcen
Bei der vorliegenden Erfindung können die CPUs durch mehrere Partitionen in serieller Art gemeinsam genutzt werden. Eine beliebige CPU im Computersystem kann von einer Partition zu einer weiteren bewegt werden, vorausgesetzt sie ist keine primäre CPU in der Partition, in der sie sich derzeit befindet, und nicht durch Einschränkungen des Systems gebunden, wie etwa durch eine verteilte Interrupt-Handhabung. Die Richtlinie, wann und wo eine CPU migrieren kann, liegt strikt beim Betriebssystem-Code, den die CPU ausführt. Bei der bevorzugten Ausführungsform migrieren CPUs durch Ausführen einer "PAL-MIGRATE"-Anweisung.
Die PAL-MIGRATE-Funktion ruft einen Satz von Schritten auf, die bewirken, dass eine CPU zwischen Instanzen bewegt wird. Dieses Verfahren der Migration kann mit anderen Aktivitäten verwendet werden, die eine CPU-Migration verlangen, und beinhaltet im wesentlichen eine Kontextumschaltung zwischen mehreren HWRPBs. Wenn eine CPU weg von einer speziellen Instanz migriert, wird ihr Kontext im HWRPB gespeichert, der der Instanz zugeordnet ist, auf der die CPU lief. Auf diese Weise kann, wenn die CPU zurück zu einer Instanz migriert, auf der sie zuvor im Betrieb war, der Kontext wiederhergestellt werden, um es der CPU zu gestatten, die Ausführung schnell wiederaufzunehmen. Die Schritte in einer PAL-Migration sind in 22A–22B gezeigt.
Die Ausführung der PAL-MIGRATE-Anweisung durch eine CPU bewirkt einen Beginn der Migrationsroutine, wie es in Schritt 2200 gezeigt ist. Der momentane Hardware-Zustand der CPU wird in Schritt 2202 gesichert, worauf die CPU die Bestimmungspartition lokalisiert und bestimmt, ob es ein gültiger Bestimmungsort ist (Schritt 2204). Schlägt der Validierungsvorgang fehl, wird in Schritt 2205 der ursprüngliche Hardware-Zustand wiederhergestellt, und die CPU nimmt den Betrieb innerhalb der ursprünglichen Partition wieder auf. Wenn die CPU die Bestimmungspartition erfolgreich validiert, wird das current_owner-Feld des CPU-Knotens im Konfigurationsbaum in Schritt 2206 gelöscht und dessen verfügbares Bit in den Je-CPU-Kennzeichen gelöscht (Schritt 2208). Die CPU-Caches werden anschließend in Schritt 2210 gelöscht.
Jeder plattformspezifische Zustand für die CPU wird in Schritt 2212 (22B) initialisiert, und das verfügbare Bit für die CPU wird in den Je-CPU-Kennzeichen in Schritt 2214 gelöscht. Das current_owner-Feld wird anschließend im CPU-Knoten des Konfigurationsbaumes eingestellt (Schritt 2216), um die ID der Partition widerzuspiegeln, zu der die CPU migriert ist. Der CPU wird anschließend ein Hardware-Kontext zugeführt (Schritt 2218). Wenn ein vorheriger Hardware-Zustand für die CPU existiert (d. h. wenn sie zuvor in dieser Partition gearbeitet hat), wird der Kontext wiederhergestellt. Gibt es keinen vorherigen Hardware-Zustand bei dieser Partition (d. h. die CPU wurde nie auf der Partition ausgeführt), oder ist der vorherige Hardware-Zustand nicht länger gültig, wird der Zustand der CPU initialisiert. Schließlich wird die Ausführung der CPU in Schritt 2220 wiederaufgenommen. Die Ausführung fährt bei der Anweisung fort, die auf die letzte Migrationsanweisung folgt, die von der CPU auf dieser Partition ausgeführt wird, oder beginnt bei Initialisierung in der Konsolen-Initialisierungsroutine als sekundärer Prozessor. Wie es in 22B gezeigt ist, endet der Vorgang, nachdem die Ausführung wiederaufgenommen wird.
Jedesmal wenn der Prozessor migriert, muss die Konsole an der Bestimmungspartition die neu migrierte CPU aufnehmen. 23 zeigt die Schritte, die von der Konsole an der Bestimmungspartition ausgeführt werden, um die Migration abzuschließen. Die Routine beginnt bei Schritt 2300 und schreitet zu Schritt 2302 fort, bei dem die Konsole eine STARTREQ-Nachricht in den TX-Puffer der migrierten CPU im Je-CPU-Schlitz plaziert und dessen TXRDY-Bit im HWRPB einstellt. Als nächstes benchrichtigt die Konsole die primäre CPU in der Partition mit Hilfe eines Interrupts, wie es in Schritt 2304 beschrieben ist. Die migrierte CPU pollt das RXRDY-Bit im HWRPB, der auf einen Befehl, wie etwa START, wartet, um den Betrieb zu beginnen, wie es in Schritt 2306 erläutert ist. Die Routine endet anschließend in Schritt 2308.
Ressourcen-Neuzuweisung nach einem Systemfehler
Eine bevorzugte Ausführungsform der Erfindung enthält eine Einrichtung zur Fehlerwiederherstellung für eine fehlerhafte Instanz. Da jede Partition im System unabhängig von den anderen Partitionen funktioniert, beeinflusst ein Fehler auf einer Partition nicht die anderen Partitionen, sondern verlangt die Wiederherstellung für die Betriebssystem-Instanz auf der betroffenen Partition wie auch für die Applikationen, die auf dieser Instanz laufen. Selbst wenn ein Fehler von der Instanz erfasst wird, die unter ihm leidet, verlangt jedoch die Korrektur eine beträchtliche Zeit, da die Partition neugestartet und all ihre Ressourcen neu initialisiert werden. In dieser Zeit werden die Verarbeitungsaufgaben der Partition ausgesetzt, und die Ressourcen können im Leerlauf bleiben, während auf die Wiederherstellung der Instanz gewartet wird. Tatsächlich kann eine Instanz nicht in der Lage sein, sich selbst neuzustarten, weshalb in diesem Fall die Ressourcen auf unbestimmte Zeit im Leerlauf bleiben könnten.
Bei der bevorzugten Ausführungsform der Erfindung ist das System derart aufgebaut, dass es dabei hilfreich ist, die Effizienz des Systems bei der Feststellung eines Fehlers in einer der Instanzen zu maximieren. Für jede Hauptpartition wird eine Sicherungspartition erzeugt und dieser derselbe Basisaufbau wie ihrer entsprechenden Hauptpartition gegeben. Dies ist schematisch in 24 gezeigt, in der die Hauptpartition 2400 mit einer primären CPU 2404 und einer Anzahl sekundärer CPUs 2408 dargestellt ist. Eine Sicherungspartition 2402 funktioniert vollständig unabhängig von der Partition 2400 und hat ihre eigene primäre CPU 2406 ihre eigene Betriebssysteminstanz. In ähnlicher Weise hat die Partition 2402 ihren eigenen HWRPB, ihre eigene Kopie des Konsolen-Programms, ihren eigenen Speicher und ihre eigenen I/O-Verbindungen und repräsentiert einen unabhängigen Knoten im Konfigurationsbaum. Zu Beginn hat die Instanz auf der Sicherungspartition 2402 keine Verarbeitungsaufgaben, während die Instanz der Hauptpartition 2400 aktiv am System beteiligt ist. In der Zeichnung ist zudem ein Bereich eines gemeinsam genutzten Speichers 2410 dargestellt, in dem Informationen gespeichert sein können, auf die sämtliche Instanzen zugreifen können.
Jede der Instanzen hält eine Kopie von Informationen, die im speziellen für die CPU-Migration nach einem Fehler in einer der Instanzen verwendet werden. Diese Informationen enthalten einen Identifikationscode (ID), der für jede der CPUs im System vorhanden ist, wobei jeder ID eine Bestimmungsinstanz (oder Partition) identifiziert, zu der die CPU, der er zugeordnet ist, migrieren sollte, wenn ihre momentane Host-Instanz in eine Fehlerbetriebsart eintritt. Die Anordnung dieser Informationen ist schematisch in 25 dargestellt, in der unterschiedliche Abschnitte des ID-Abschnittes des Speichers so dargestellt sind, dass sie jeweils einen Bestimmungs-ID enthalten. Die benachbarten CPU-Identifikationen ordnen jeden der Bestimmungs-IDs der geeigneten CPU zu. Wenn eine Fehler erfasst wird, kann der geeignete Speicherort untersucht werden, um die Zielinstanz für eine gegebene CPU zu bestimmen, wobei diese Informationen verwendet werden können, um eine gesteuerte Migration zur neuen Instanz auszuführen. Mit der Anordnung von Partitionen, die in 24 gezeigt ist, kann beispielsweise bei vielen, wenn nicht allen, der sekundären CPUs der Partition 2400 die Sicherungspartition (Partition 2402) als deren Ziel gekennzeichnet werden. Wenn die Instanz auf der Partition 2400 eine Fehlfunktion erfahren sollte, würden somit diese CPUs von der Partition 2400 zur Partition 2402 migrieren. Der Fachmann wird jedoch verstehen, dass es unter bestimmten Umständen wünschenswert sein kann, eine oder mehrere der CPUs der Partition 2400 insgesamt zu einer anderen Partition zu senden. Mit den virtuellen Ressourcenfunktionen der Instanz kann weiterhin die neu erworbene CPU automatisch in den aktiven Satz gebracht werden, indem beispielsweise der Autostart-Satz verwendet wird, wie es oben beschrieben ist.
Während des Fehlers einer Instanz folgt das System einer Abfolge von Schritten, die darauf ausgelegt sind, den Nutzungsverlust der Ressourcen der fehlerhaften Instanz zu minimieren und in einigen Fällen zu versuchen, sämtliche Vorgänge, die mit der Instanz auf der fehlerhaften Partition ausgeführt werden, zu einer neuen Instanz und Partition so schnell wie möglich zu übertragen. Diese Schritte sind im allgemeinen im Flussdiagramm von 26A und 26B beschrieben.
Die Abfolge von Ereignissen, die einem erfassten Fehler folgen, beginnt beim Startschritt 2600, der in 26A gezeigt ist. Nachdem der Fehler erfasst wurde, übernimmt die Betriebssystem-Instanz, in der der Fehler auftrat, die Steuerung des Ausführungskontextes sämtlicher CPUs in ihrem aktiven Satz (Schritt 2602). Die verbleibenden Systemabschaltprozeduren werden durch die primäre CPU der Partition fortgeführt, während die sekundären CPUs beliebige Maßnahmen ergreifen, die für ihre Migration erforderlich sind. In Schritt 2604 weist die primäre CPU die aktive sekundäre CPU der fehlerhaften Instanz an, jeweils ihren Verarbeitungskontext in einen gewählten Bereich des gemeinsam genutzten Speichers des Systems auszugeben, worauf sie angewiesen werden, den Migrationsvorgang zu beginnen. Sobald sämtliche der aktiven sekundären CPUs ihre Verarbeitungskontexte ausgegeben haben, schreitet die primäre CPU zur nächsten Aktion fort (Schritt 2606). Da sich einige der sekundären CPUs nicht in der aktiven Betriebsart befinden können, muss die primäre CPU bestätigen, dass jede der sekundären CPUs mit dem Fehlerwiederherstellungsvorgang fortschreitet. Gibt es beliebige der sekundären CPUs, die sich im Konfigurationssatz jedoch nicht im aktiven Satz der in Frage kommenden Instanz befinden, ruft die primäre CPU eine separate Migrationsfunktion in Schritt 2608 auf, um die gestoppten CPUs zu einer beliebigen festgelegten Bestimmungspartition zu bewegen.
Der Fehlerwiederherstellungsvorgang wird in 26B fortgeführt, wobei die Kontinuität zwischen 26A und 26B mit den Verbinderknoten "A" gekennzeichnet ist. In Schritt 2610 führt die primäre CPU eine Ausgabe der Daten aus, die im Speicher gespeichert sind, der von der fehlerhaften Instanz gesteuert wird, und kopiert sie zu einem neuen Ort. Wie es in Schritt 2612 von 26B gezeigt ist, sendet die primäre CPU der fehlerhaften Instanz anschließend eine Konsolen-"Rückruf"-Anweisung, die kennzeichnet, dass sie in die Konsolenbetriebsart eingetreten ist, und bewirkt, dass das Konsolen-Programm zahlreiche unterschiedliche Aufgaben ausführt. Eine dieser Aufgaben besteht darin, die System-Inkarnationszahl zu erhöhen, die immer dann geändert wird, wenn es eine Änderung im Konfigurationsbaum gibt. Die Konsole initiiert zudem die Erzeugung eines Zwischenprozessor-Interrupts (IPINT), der bewirkt, dass sämtliche anderen Instanzen die Inkarnationszahl betrachten, feststellen, dass sie sich geändert hat, und den Konfigurationsbaum untersuchen und die Änderung des Zustands der fehlerhaften Instanz im Vorgang identifizieren. Weiterhin wird die Konsole einen geeigneten Zustandscode in den Je-CPU-Datenbits für die primäre CPU einstellen, sobald sie das Abschalten (d. h. den Eintritt in die Konsolen-Betriebsart) der primären CPU feststellt, ohne dass es die Möglichkeit gibt, zu einer Funktion auf der vorliegenden Instanz zurückzukehren. Die primäre CPU, die in die Konsolen-Betriebsart eintritt und die Konsole veranlasst, den zuvor erwähnten Zustandscode einzustellen, ist in Schritt 2614 gezeigt. An diesem Punkt ist die Partition vollständig außer Kraft gesetzt und sind die Fehlerschritte abgeschlossen.
Sobald eine sekundäre CPU (im aktiven Satz) von der primären CPU angewiesen wird, eine Fehlermigration auszuführen, führt sie eine Abfolge von Schritten aus, die in 27 dargestellt sind. Zunächst gibt die sekundäre CPU ihren Verarbeitungskontext (2700) aus, wie es durch die primäre CPU angewiesen wird. Anschließend pollt sie den geeigneten Abschnitt der Speicheranordnung, die Ausfallsicherungs-IDs enthält, um zu bestimmen, wohin, wenn überhaupt, migriert werden soll (Schritt 2702). Sobald die Ziel-ID abgerufen ist, vergleicht der Prozessor diese mit der ID der vorliegenden Partition (Schritt 2704). In bestimmten Fällen kann es gewünscht sein, eine CPU im Falle eines Fehlers auf dieser Partition nicht zu migrieren. In diesem Fall ist der Ziel-ID, der für die in Frage kommende CPU geladen wird, der ID der vorliegenden Partition. Wenn die CPU in Schritt 2704 ermittelt, dass der Ziel-ID und der ID der vorliegenden Partition gleich sind, tritt sie somit einfach in die Konsolen-Betriebsart ein und der Vorgang endet. Unterscheidet sich jedoch der Ziel-ID vom vorliegenden ID, migriert die CPU zur neuen Partition unter Verwendung eines der bereitgestellten Verfahren, worauf der Vorgang abgeschlossen ist.
Bei einer Variation der obigen Ausführungsform kann die Interrupt-Handhabungseinrichtung zudem damit beauftragt sein, bestimmte Applikationen über den Fehler zu unterrichten. Bei dieser alternativen Ausführungsform stellt die IPINT-Handhabungseinrichtung einen Registriervorgang bereit, durch den sich spezielle Applikationen für die Benachrichtigung eines speziellen Ereignisses "registrieren" können. Mit Hilfe dieses Mechanismus' kann jede beliebige Applikation von der Änderung im Konfigurationsbaum benachrichtigt werden und kann bestimmen, dass ein Fehler aufgetreten ist. Ist die Applikation eine Kopie einer Applikation, die auf der fehlerhaften Instanz lief, stellt dies einen Auslöser für die Applikation auf der Sicherungsinstanz bereit, Verarbeitungsaktivitäten zu beginnen, anstelle für die Applikation, die auf der fehlerhaften Instanz lief.
36. ZUWEISUNG DER DAUERZUGEHÖRIGKEIT VON RESSOURCEN IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (28–29)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardwaregrenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Die Erfindung kann eine Einrichtung zum Bewegen eines Prozessor von einer ersten Partition zu einer zweiten Partition beinhalten. Eine derartige Bewegung erfordert die Ausführung einer Anweisung durch den sich bewegenden Prozessor, so dass dessen Einwilligung zur Bewegung (und jene der Betriebssysteminstanz, auf der er läuft) sichergestellt ist. Wird eine Bewegung initiiert, speichert der Prozessor seinen derzeitigen Hardware-Zustand und lädt einen Hardware-Zustand, den er während einer vorherigen Ausführung innerhalb der zweiten Partition innehatte. Somit nimmt der Prozessor den Betrieb in der zweiten Partition von dort auf, wo er ihn zuvor verlassen hatte. Gibt es keinen gespeicherten Hardware-Zustand auf der Partition, zu der der Prozessor migriert, wird er in einen initialisierten Zustand versetzt.
Die vorliegende Erfindung verfügt über eine Interaktion zwischen den Partitionen, die es einem Prozessor gestattet, von einer Partition zu einer weiteren Partition zu migrieren, ohne dass ein Neustart des gesamten Systems erforderlich ist. Software, die auf ihrer momentanen Partition läuft, oder ein primärer Prozessor auf seiner Partition können dem zu bewegenden Prozessor eine Aufforderung zustellen, dass er einen Migrationsvorgang ausführt. Eine derartige Migration kann mit oder ohne Unterbrechung des Betriebssystems erfolgen, in dem er sich befindet. Das heißt, der Prozessor kann einfach stillgelegt und neu zugewiesen werden, während der übrige Teil des Systems mit dem Betrieb fortfährt, oder die Ressourcen in dessen Partition können angehalten werden, und es wird ein Konsolen-Programm aufgerufen, um die Bewegung zu koordinieren.
Um die Prozessoren im System zu verfolgen, hat jede Partition einen Satz von Hardware-Kennzeichen, der Kennzeichen beinhaltet, die die Partition kennzeichnen, der jeder der Prozessoren jeweils zugeordnet ist. Die Hardware-Kennzeichen zeigen zudem an, wann ein gegebener Prozessor verfügbar ist, um beim SMP-Betrieb verwendet zu werden. Durch Aktualisieren dieser Kennzeichen immer dann, wenn der Prozessor migriert, ist der derzeitige Zustand jedes Prozessors bekannt und wird in den Hardware-Kennzeichen für die Verwendung bei beliebigen Neustarts des Systems gehalten.
Bei der bevorzugten Ausführungsform wird den CPUs zudem eine Dauerzugehörigkeits-Zuweisung gegeben, die sie an eine bestimmte der Partitionen bindet. Dies gestattet es den CPUs, jeweils einer entsprechenden Partition während der Systeminitialisierung zugewiesen zu werden. Die Zugehörigkeits-Zuweisung für eine gegebene CPU wird durch die Inhalte eines speziellen Speicherortes im nicht flüchtigen Speicher gekennzeichnet. Wenn das System initialisiert wird, wird eine beliebige CPU, ohne dass eine gültige Besitzerpartition in ihrem Besitzerfeld gekennzeichnet ist, einer willkürlichen Partition zugewiesen, bis eine Neuzuweisung erfolgt. Die Dauerzugehörigkeit einer CPU kann auch geändert werden, wenn die CPU eine Anweisung zur Neuzuweisung erhält. Sobald das System initialisiert ist, kann eine Migration der CPU durch eine Änderung der Inhalte eines zweiten Speicherortes erfolgen, der kennzeichnet, dass die Partition einen vorübergehenden Besitz der CPU hat und der sich im flüchtigen Speicher befindet.
Dauerhafte Zuweisung von Ressourcen
Mit der vorliegenden Erfindung können CPUs in serieller Art und Weise von mehreren Partitionen gemeinsam genutzt werden. Jede beliebige CPU im Computer system kann von einer Partition zu einer weiteren Partition bewegt werden, vorausgesetzt sie ist keine primäre Partition an dem Ort, an dem sie sich zu diesem Zeitpunkt befindet, und ist nicht an Systembeschränkungen, wie etwa eine verteilte Interrupt-Handhabung gebunden. Während der "momentane Besitzer" einer gegebenen CPU fliegend gewechselt werden kann, wird jedoch ein "Dauerbesitzer" ebenfalls eingerichtet, der eine CPU mit einer speziellen Partition identifiziert, wenngleich selbst dieser dauerhafte Besitz innerhalb des Systems geändert werden kann.
Die Zugehörigkeit der CPUs im System wird durch den Konfigurationsbaum eingerichtet, der eine CPU-Knotenstruktur einer Partitionsknotenstruktur zuordnet. Wenn eine primäre CPU den Betrieb initialisiert, erzeugt sie den Konfigurationsbaum aus der momentanen Hardware-Konfiguration und den gespeicherten Software-Konfigurationsinformationen. Jede CPU ist entweder eine Partition zugewiesen (d. h. ist zugehörig) oder nicht zugewiesen (d. h. nicht zugehörig). Die Zugehörigkeitsinformationen, die eine CPU betreffen, basieren auf dem Inhalt des Besitzerfeldes ihres CPU-Knotens im Konfigurationsbaum. Die Details, die die anfängliche Zuweisung einer CPU im System betreffen, sind in 28 gezeigt.
Das System wird initialisiert und der Vorgang beginnt bei Schritt 2800. Wenn der Konfigurationsbaum aufgebaut wird, wird das Besitzerfeld des geeigneten CPU-Knotens untersucht (Schritt 2802). Ist das Besitzerfeld mit einem Code gefüllt, der einen bestimmten Abschnitt kennzeichnet (wie er in Schritt 2804 als geprüft dargestellt ist), wird die CPU anschließend auf dieser Partition initialisiert (Schritt 2806). Anschließend stellt die CPU selbst ihr verfügbares Bit ein (Schritt 2808) und fragt eine Teilnahme am SMP-Betrieb auf der Partition an (Schritt 2810). Der Zuweisungsvorgang ist dann abgeschlossen.
Wenn in Schritt 2804 bestimmt wird, dass es keinen gültigen Code gibt, der die Zugehörigkeit der CPU zu einer gegebenen Partition kennzeichnet, nimmt die CPU an einem HWRPB-Kontext teil, wie es von der Konsole angewiesen wird (Schritt 2805). Das heißt, sie wird von der Konsole angewiesen, an einer willkürlichen Partition teilzunehmen. Die CPU stellt jedoch nicht ihr verfügbares Bit ein, weshalb von ihr nicht erwartet wird, dass sie an einem SMP-Vorgang teilnimmt.
Sie tritt anschließend in einen Wartezustand ein, während dessen sie fortwährend ihr Besitzerfeld pollt (Schritte 2807 und 2809). Wenn das Besitzerfeld mit dem Code für eine gültige Partition gefüllt ist, lokalisiert die CPU diese Partition und migriert, sofern dies erforderlich ist, zu dieser (Schritt 2811). Sie stellt anschließend ihr verfügbares Bit ein (Schritt 2808) und fragt die Teilnahme an einem SMP-Vorgang auf der neuen Partition an (Schritt 2810). Diese Partition bleibt der "Dauerbesitzer" dieser CPU, bis eine Änderung an ihrem Besitzerfeld vorgenommen wird.
Die Dauerzugehörigkeit einer CPU kann mit Interaktion der Konsole geändert werden. Dieser Vorgang ist im Flussdiagramm von 29 dargestellt, der bei Schritt 2900 beginnt. In Schritt 2902 führt die Betriebssystem-Instanz der Partition, auf der die in Frage kommende CPU läuft, eine HALT-Anweisung mit einem HALT_REQUESTED-Code von DEASSIGN aus. Das heißt, ein Halt-Code wird in die HALT_REQUESTED-Bits des Je-CPU-STATE_FLAGS-Feldes geladen, das kennzeichnet, dass die Zuweisung der CPU aufgehoben werden soll. Die CPU antwortet auf diesen Code in vielfältiger Weise. Sie löscht das Besitzerfeld (Schritt 2904) und ihr current_owner-Feld (Schritt 2906) im CPU-Knoten. Sie löscht zudem ihr verfügbares Bit (Schritt 2908). Die CPU beginnt anschließend ihr Besitzerfeld zu untersuchen, das darauf wartet, dass in ihm ein gültiger Partitions-Code plaziert wird. Das heißt, die CPU schreitet zu Schritt 2802 von 28 fort und führt den Zuweisungsvorgang aus, der oben beschrieben ist. Dies ist durch den Verbinder "A" sowohl in 28 als auch 29 dargestellt.
Befindet sich eine sekundäre CPU in der Konsolen-I/O-Betriebsart, kann die Aufhebung ihrer Zuweisung ebenfalls durch die primäre CPU der Partition initiiert werden, die eine DEASSIGN-Nachricht zum RX-Puffer der sekundären CPU sendet. Dadurch wird die CPU veranlasst, den Satz von Schritten zu initiieren, der in 29 gezeigt ist.
Die Dauerzugehörigkeits-Eigenschaft einer CPU liefert wichtige Informationen, die insbesondere für das anfängliche Einschalten des Systems hilfreich sind. Wenn der Konfigurationsbaum aufgebaut wird, wird die Dauerzugehörigkeit jeder CPU verwendet, um die Partitionen aufzubauen. Später wird das current_owner-Feld (das die Partition kennzeichnet, die eine gegebene CPU steuert) verwendet, um zu verfolgen, wo jede CPU zu einem gegebenen Zeitpunkt ihre Ausführung durchführt. Die Dauerzugehörigkeits-Informationen werden jedoch beibehalten, um eine zukünftige Verwendung bei der Neuorganisation des Systems oder eine zukünftige Neuinitialisierung des Systems zuzulassen. Demzufolge werden die Dauerzugehörigkeitsdaten im nvRAM (d. h. nicht flüchtige RAM) gespeichert, während die Daten für vorübergehende Zugehörigkeit im flüchtigen Speicher gespeichert werden.
I. MIGRATIONSPROZESSOREN IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (22A–27)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardwaregrenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Die Erfindung kann eine Einrichtung zum Bewegen eines Prozessors von einer ersten Partition zu einer zweiten Partition beinhalten. Eine derartige Bewegung erfordert die Ausführung einer Anweisung durch den sich bewegenden Prozessor, so dass dessen Einwilligung zur Bewegung (und jene der Betriebssysteminstanz, auf der er läuft) sichergestellt ist. Wird eine Bewegung initiiert, speichert der Prozessor seinen derzeitigen Hardware-Zustand und lädt einen Hardware-Zustand, den er während einer vorherigen Ausführung innerhalb der zweiten Partition innehatte. Somit nimmt der Prozessor den Betrieb in der zweiten Partition von dort auf, wo er ihn zuvor verlassen hatte. Gibt es keinen gespeicherten Hardware-Zustand auf der Partition, zu der der Prozessor migriert, wird er in einen initialisierten Zustand versetzt.
Die vorliegende Erfindung verfügt über eine Interaktion zwischen den Partitionen, die es einem Prozessor gestattet, von einer Partition zu einer weiteren Partition zu migrieren, ohne dass ein Neustart des gesamten Systems erforderlich ist. Software, die auf seiner momentanen Partition läuft, oder ein primärer Prozessor auf seiner Partition können dem zu bewegenden Prozessor eine Aufforderung zustellen, dass er einen Migrationsvorgang ausführt. Eine derartige Migration kann mit oder ohne Unterbrechung des Betriebssystems erfolgen, in dem er sich befindet. Das heißt, der Prozessor kann einfach stillgelegt und neu zugewiesen werden, während der übrige Teil des Systems mit dem Betrieb fortfährt, oder die Ressourcen in dessen Partition können angehalten werden, und es wird ein Konsolen-Programm aufgerufen, um die Bewegung zu koordinieren.
Um die Prozessoren im System zu verfolgen, hat jede Partition einen Satz von Hardware-Kennzeichen, der Kennzeichen beinhaltet, die die Partition kennzeichnen, der jeder der Prozessoren jeweils zugeordnet ist. Die Hardware-Kennzeichen zeigen zudem an, wann ein gegebener Prozessor verfügbar ist, um beim SMP-Betrieb verwendet zu werden. Durch Aktualisieren dieser Kennzeichen immer dann, wenn der Prozessor migriert, ist der derzeitige Zustand jedes Prozessors bekannt und wird in den Hardware-Kennzeichen für die Verwendung bei beliebigen Neustarts des Systems gehalten.
Laufzeitmigration von Ressourcen
Wenn eine Betriebssystem-Instanz abstürzt, werden die CPUs, die auf der Partition aktiv sind, weiterhin ein Teil derselben Instanz beim Neustart sein. Die CPUs migrieren nicht automatisch zu ihren normalen "Besitzern". Auch migrieren CPUs, die einer Partition "zugehörig" sind, nicht zurück zu einer Betriebssysteminstanz, die abstürzt oder neustartet. Das verfügbare Bit in den Je-CPU-Kennzeichen im HWRPB kennzeichnet die momentane Zugehörigkeit. Dies wird auch im current_owner-Feld des CPU-Knotens im Konfigurationsbaum widergespiegelt.
Das Betriebssystem kann eine automatische Migration von sekundären CPUs als Teil ihrer Absturzlogik implementieren. Das heißt, wenn eine sekundäre CPU das Ende ihrer Absturzlogik erreicht und normalerweise in einen Wartezustand eintreten würde, kann das Betriebssystem eine Richtlinie einsetzen, um zu bewirken, dass die CPUs anstelle dessen zu einer vordefinierten Partition migrieren. Dies würde den Einsatz von gerichteten Warm-Ausfallsicherungs-Systemen zulassen, bei denen die CPUs unverzüglich an der warmen Sicherungspartition verfügbar sind, wenn die primäre Applikationspartition fehlerhaft ist.
J. PROZESSORMIGRATION VON UNTERSCHIEDLICHEN PROZESSORZUSTÄNDEN IN EINEM MULTIPROZESSOR-COMPUTERSYSTEM (30A–32B)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen e lektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardwaregrenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Die Erfindung kann eine Einrichtung zum Bewegen eines Prozessors von einer ersten Partition zu einer zweiten Partition beinhalten. Eine derartige Bewegung erfordert die Ausführung einer Anweisung durch den sich bewegenden Prozessor, so dass dessen Einwilligung zur Bewegung (und jene der Betriebssysteminstanz, auf der er läuft) sichergestellt ist. Wird eine Bewegung initiiert, speichert der Prozessor seinen derzeitigen Hardware-Zustand und lädt einen Hardware-Zustand, den er während einer vorherigen Ausführung innerhalb der zweiten Partition innehatte. Somit nimmt der Prozessor den Betrieb in der zweiten Partition von dort auf, wo er ihn zuvor verlassen hatte. Gibt es keinen gespeicherten Hardware- Zustand auf der Partition, zu der der Prozessor migriert, wird er in einen initialisierten Zustand versetzt.
Die vorliegende Erfindung verfügt über eine Interaktion zwischen den Partitionen, die es einem Prozessor gestattet, von einer Partition zu einer weiteren Partition zu migrieren, ohne dass ein Neustart des gesamten Systems erforderlich ist. Software, die auf seiner momentanen Partition läuft, oder ein primärer Prozessor auf seiner Partition können dem zu bewegenden Prozessor eine Aufforderung zustellen, dass er einen Migrationsvorgang ausführt. Eine derartige Migration kann erfolgen, wenn ein Prozessor unter Steuerung einer Betriebssystem-Instanz auf seiner momentanen Partition arbeitet, oder wenn er sich in einem gestoppten Zustand befindet und unter der Steuerung eines System-Konsolen-Programms arbeitet. Die Zuweisung der Prozessor kann zudem unbestimmt aufgehoben sein, d. h. es ist ihm keine Partition zugewiesen, bevor er einer neuen Partition zugewiesen wird.
Laufzeitmigration von Ressourcen
Eine CPU-Migration kann aus einem unterschiedlichen Satz von Schritten in Abhängigkeit des Zustands der CPU bestehen, wann die Migration begonnen wird, und der Weise, in der die Migration ausgeführt wird. Die bevorzugten Verfahren der CPU-Migration sind detaillierter unten beschrieben. Diese Verfahren beinhalten: 1) die direkte Migration einer CPU, die unter der Betriebssystem-Instanz ihrer Partition arbeitet; 2) die direkte Migration einer CPU, die momentan in der Konsolen-Betriebsart arbeitet; und 3) die Migration einer CPU durch Übergang derselben durch einen nicht zugewiesenen Zustand.
Wenn eine CPU unter Anweisung des Betriebssystems arbeitet, wird der Migrationsvorgang als "Halt"-Migration bezeichnet, da die CPU angehalten werden muss, bevor sie über die PAL_MIGRATE-Anweisung erneut zugeordnet wird. Die Schritte, die für die Halt-Migration notwendig sind, sind in 30A und 30B gezeigt.
Beginnend bei Schritt 3000, schreitet die Migrationsroutine zu Schritt 3002 fort, bei dem die migrierende CPU in Erwiderung auf eine Anweisung von der primären CPU zu migrieren, einen speziellen HALT_MIGRATE-Code im REASON_FOR_HALT-Je-CPU-Feld des HWRPB plaziert. Als nächstes plaziert in Schritt 3004 die CPU den Bestimmungspartitions-ID in das REASON_FOR_HALT-Feld. Anschließend führt die CPU eine HALT-Anweisung aus (Schritt 3006). Das Betriebssystem ist für den Stilllegungsvorgang der CPU und eine Beendigung der SMP-Teilnahme der CPU vor der Ausführung des HALT verantwortlich. Das tatsächliche Verhalten dieser Teilschritte ist betriebssystemspezifisch und herkömmlich.
Wenn eine CPU einen HALT mit einem HALT_MIGRATE-Code im REASON_FOR_HALT-Je-CPU-Feld ausführt, wird die Steuerung zum Konsolen-HALT-Eintrittspunkt übertragen, wie es in Schritt 3008 gekennzeichnet ist. Die Konsole bezieht anschließend den Partitions-ID des Bestimmungsortes vom REASON_FOR_HALT-Je-CPU-Feld (Schritt 3010) und löscht das REASON_FOR-HALT-Feld, wie es in Schritt 3012 dargestellt ist. Als nächstes bestimmt die Konsole, ob der HALT_MIGRATE-Vorgang gültig ist, in Schritt 3014. Ist er gültig, löscht die Konsole das current_owner-Feld im CPU-Knoten des Konfigurationsbaumes in Schritt 3016 und führt eine PAL_MIGRATE-Anweisung in Schritt 3018 aus, worauf die Routine in Schritt 3020 endet. Wenn in Schritt 3014 die Konsole bestimmt, dass der HALT_MIGRATE-Vorgang nicht gültig ist (es ist beispielsweise ein ungültiger Partitions-ID festgelegt), führt die Konsole die Schritte in 30C aus.
Wie es in 30C gezeigt ist, führt eine Bestimmung durch die Konsole, dass ein HALT_MIGRATE-Vorgang ungültig ist, zunächst zur Löschung des REASON_FOR_HALT-Je-CPU-Feldes (Schritt 3022) und zum Verbleib in einem HALT-Zustand auf der momentanen Partition. In Schritt 3024 plaziert die Konsole eine STARTREQ-Nachricht in den TX-Puffer der CPU im Je-CPU-Schlitz und stellt in Schritt 3026 ihr TXRDY-Bit im HWRPB ein. Als nächstes unterrichtet die Konsole die primäre CPU in der Partition mit Hilfe eines Interrupts, wie es in Schritt 3028 dargestellt ist. Anschließend pollt die Konsole das RXRDY-Bit im HWRPB, der auf einen Befehl, wie etwa START, DEASSIGN oder MIGRATE, wartet, um einen Vorgang zu beginnen, wie er in Schritt 3030 dargestellt ist. Anschließend en det die Routine. Wird der HALT_MIGRATE-Vorgang nicht validiert, löscht die Konsole nicht das verfügbare Bit in den Je-CPU-Kennzeichen und löscht nicht das current_owner-Feld im CPU-Knoten im Konfigurationsbaum.
Befindet sich eine CPU bereits in der Konsolen-Betriebsart, unterscheiden sich die Schritte geringfügig von jenen, die oben beschrieben sind. Eine CPU, die sich in der Konsolen-I/O-Betriebsart befindet, bei der das verfügbare Bit eingestellt ist und bei der das current_owner-Feld im Konfigurationsbaum eingestellt ist, pollt den CPU-RX-Puffer, der auf einen Befehl von der primären CPU wartet, auf der das Betriebssystem läuft. Die folgenden Schritte zum Migrieren dieser CPU sind in 31 gezeigt.
Das dargestellte Verfahren beginnt bei Schritt 3100 und schreitet zu Schritt 3102 fort, bei dem die primäre CPU einen MIGRATE-Befehl in den RX-Puffer der CPU plaziert, die migriert werden soll. Die primäre CPU stellt anschließend das RXRDY-Bit der CPU ein, um diese von der Gegenwart der Migrationsanweisung zu unterrichten (Schritt 3104). Das current_owner-Feld der migrierenden CPU wird anschließend durch die Konsole in Vorbereitung auf deren Neuzuweisung gelöscht (Schritt 3106). Die PAL_MIGRATE-Anweisung (22A–22B) wird anschließend aufgerufen, worauf der Vorgang in Schritt 3020 endet.
Wenn eine CPU unter ihrer Betriebssystem-Instanz arbeitet, besteht ein Verfahren zur Migration derselben, das keine unverzügliche Kennzeichnung der Bestimmungspartition (wie bei der Halt-Migration, die oben beschrieben wurde) verlangt, darin, dass zuerst die Zuweisung der CPU aufgehoben wird und anschließend diese einer anderen Partition neu zugewiesen wird. Dieses Verfahren ist in 32A und 32B gezeigt.
Das Verfahren beginnt in 32A bei Schritt 3200 und schreitet zu Schritt 3202 fort, bei dem die primäre CPU in der Partition, in der sich die migrierende CPU befindet, einen DEASSIGN-Code im RX-Puffer der migrierenden CPU plaziert. Die CPU wird anschließend von der primären CPU angewiesen, eine HALT-Anweisung auszuführen, was sie auch tut (Schritt 3204). Das Vorhandensein eines DEASSIGN-Codes, wenn HALT ausgeführt wird, veranlasst die CPU, das Be sitzerfeld im Konfigurationsbaum wie auch das AVAILABLE-Bit und das current_owner-Feld zu löschen. Die CPU arbeitet anschließend in der Konsolenbetriebsart und nimmt am HWRPB-Kontext teil, wie es durch die Konsole angewiesen wird.
Nicht zugewiesen pollt die CPU ohne Unterbrechung ihr Besitzerfeld (Schritte 3208 und 3210). Wenn das Besitzerfeld mit dem Code für eine gültige Partition gefüllt ist, lokalisiert die CPU diese Partition und migriert, wenn dies erforderlich ist, zu dieser (Schritt 3212 – 32B). Anschließend stellt sie ihr verfügbares Bit ein (Schritt 3214) und fragt eine Teilnahme am SMP-Vorgang auf der neuen Partition an. (Schritt 3216). Die Partition bleibt der "Dauerbenutzer" dieser CPU, bis eine Änderung an deren Besitzerfeld vorgenommen wird.
Wenn eine Betriebssystem-Instanz abstürzt, dann sind die CPUs, die in der Partition aktiv sind, weiterhin Teil derselben Instanz beim Neustart. Die CPUs migrieren nicht automatisch zu ihren nominalen "Besitzern". Auch migrieren CPUs, die einer Partition "zugehörig" sind, nicht zurück zu einer Betriebssystem-Instanz, die abstürzt oder neustartet. Das verfügbare Bit in den Je-CPU-Kennzeichen im HWRPB kennzeichnet die momentane Zugehörigkeit. Dies wird auch im current_owner-Feld des CPU-Knotens im Konfigurationsbaum widergespiegelt.
Das Betriebssystem kann eine automatische Migration von sekundären CPUs als Teil ihrer Absturzlogik implementieren. Das heißt, wenn eine sekundäre CPU das Ende ihrer Absturzlogik erreicht und normalerweise in einen Wartezustand eintreten würde, kann das Betriebssystem eine Richtlinie einsetzen, um zu bewirken, dass die CPUs anstelle dessen zu einer vordefinierten Partition migrieren. Dies würde den Einsatz von gerichteten Warm-Ausfallsicherungs-Systemen zulassen, bei denen die CPUs unverzüglich an der warmen Sicherungspartition verfügbar sind, wenn die primäre Applikationspartition fehlerhaft ist.
K. KOMMUNIKATION IN EINEM MULTIPROZESSORSYSTEM (33A–34B)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem einzigen Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssystems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardwaregrenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher, können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Beim vorliegenden Aspekt der Erfindung sind die einzelnen Instanzen in der Lage, zwischen den Instanzen zu kommunizieren. Das heißt, eine erste Instanz, die auf einer ersten Partition läuft, kann mit einer zweiten Instanz kommunizieren, die auf einer zweiten Partition läuft. Diese Kommunikation nutzt den gemeinsam genutzten Speicher im System und gestattet es einer Instanz, aktiv eine weitere Instanz zu benachrichtigen, die an anderer Stelle im System läuft. Die zwei bevorzugten Verfahren der Kommunikation bestehen in der Einzelbitmeldung und in der paketierten Datenübertragung.
Die Einzelbitmeldung nutzt die Tatsache, das eine Zahl vorbestimmter Ereignisse sämtlichen Instanzen des System bekannt ist, und kann daher durch ein Bit je Ereignis dargestellt werden. Somit ist jeder Instanz in ihrem gemeinsam genutzten Speicher ihr eigener Meldungsbitvektor zugeordnet, der ein Satz von Bits ist, von denen jedes ein anderes der vorbestimmten Ereignisse kennzeichnet. Eine erste Instanz kann dann eine zweite Instanz vom Auftreten eines des vorbestimmten Ereignisse unterrichten, indem auf den Bitvektor der zweiten Partition im gemeinsam genutzten Speicher zugegriffen wird und der Wert des Bits entsprechend diesem Ereignis geändert wird. Die erste Instanz benachrichtigt anschließend die zweite Instanz mit einem Interrupt, wodurch sie veranlasst wird, ihren Bitvektor zu prüfen. Findet sie ein abgeändertes Bit, verwendet sie die Position dieses Bits im Bitvektor als einen Index, um im Speicher eine Routinen-Aufrufanweisung zu lokalisieren, die eine Verarbeitungsroutine initiiert, die sich für das Ereignis eignet, das von diesem Bit dargestellt wird.
Die paketierte Datenübertragung nutzt ebenfalls den gemeinsam genutzten Speicher, beinhaltet jedoch, dass die erste Instanz die erforderliche Speichermenge bestimmt und anschließend diesen Raum im gemeinsam genutzten Speicher zuordnet. Zudem befindet sich im gemeinsam genutzten Speicher der Listenkopf einer Paketverarbeitungs-Warteschlange für jede der Instanzen. Nachdem die erste Instanz die paketierten Daten im gemeinsam genutzten Speicher gespeichert hat, lokalisiert sie den Listenkopf der Paketverarbeitungs-Warteschlange für die zweite Instanz und setzt die notwendigen Informationen, die die paketierten Daten betreffen in den Listenkopf. Die erste Instanz verwendet anschließend eine Einzelbitmeldung, wie jene die oben beschrieben wurde, um der zweiten Instanz zu signalisieren, dass die paketierten Daten zum Abruf bereit sind. Mit anderen Worten stellt die erste Instanz ein Bit im Meldungsbitvektor der zweiten Instanz ein, das dem Ereignis der paketierten Daten entspricht, die für die Verarbeitung durch die zweite Instanz bereit sind. Sie benachrichtigt die zweite Instanz durch einen Interrupt, so dass sie den Bitvektor überprüft und das Ereignis erkennt. Die zweite Instanz verarbeitet anschließend ihre Paketverarbeitungs-Warteschlange und ruft die paketierten Daten ab. Vorzugsweise kann eine Komponenten-ID innerhalb der paketierten Daten von der zweiten Instanz als Index zu einem Speicherort verwendet werden, an dem sich die Abruffunktion für eine geeignete Verarbeitungsroutine (d. h. eine Routine, die das korrekte Datenformat verwendet) finden kann.
Neukonfiguration des Speichers
Der Aufbau der Seitenrahmenzahl-(PFN-)Datenbank gestattet es dem Speicher, durch Software-Steuerung in die oder aus der Betriebssystem-Instanz neukonfiguriert zu werden. Privater Speicher kann neukonfiguriert werden, um gemeinsam genutzt zu werden, gemeinsam genutzter Speicher kann neukonfiguriert werden, um privat zu sein, und Speicher, der für eine Partition privat ist, kann neukonfiguriert werden, um für eine weitere Partition privat zu sein. Speicher, der privat oder gemeinsam genutzt ist, kann ebenso neukonfiguriert werden, um nicht zugehörig zu sein. Die Speicherneukonfiguration kann das Hardware-Hot-In-Swapping oder das -Hot-Out-Swapping unterstützen. Befindet sich der Speicher in einem "nicht zugehörigen" Zustand in einem Konfigurationsbaum, kann er zu einem privaten Speicher einer Instanz oder als Teil des gemeinsam genutzten Speichers in einer Gemeinschaft neukonfiguriert werden. Wird der Speicher einem In-Swapping in ein System unterzogen, wird der Speicher zunächst in den nicht zugehörigen Zustand versetzt. Bevor der Speicher einem Out-Swapping aus einem System unterzogen werden kann, muss er sich darüber hinaus in einem nicht zugehörigen Zustand befinden. Um das Speicher-Hot-Swapping zu unterstützen, müssen somit die Betriebssystem-Instanz und die Konsolen-Software den Speicher in den und aus dem nicht zugehörigen Zustand neukonfigurieren. Wird der Speicher neukonfiguriert, wird der Seitenbereich beispielsweise zu 8 Megabyte (MB) angepasst (die Systemseitenzahl im Quadrat, geteilt durch 8 Bytes). Der Bereich der Seiten ist ein Vielfaches von 8 MB in der Größe, und wenn Seiten innerhalb des Bereiches, der aus dem System neukonfiguriert werden soll, in Verwendung sind, können andere Einschränkungen angewendet werden, wie es im folgenden beschrieben ist.
Neuer Speicher kann dem System zu einem beliebigen Zeitpunkt hinzugefügt werden, da die PFN-Datenbank derart bemessen ist, dass sie sämtlichen möglichen Speicher enthalten kann, der einem In-Swapping unterzogen werden kann, wobei die neuen Seiten immer verwendet werden können, um die PFN-Datenbankeintragsseiten auszumachen. Um Speicher aus einem System zu entfernen, wird zunächst ermittelt, ob der Bereich der Seiten privat, gemeinsam genutzt oder nicht zugehörig ist. Ist der Speicher bereits als nicht zugehörig markiert, wird er als entfernt betrachtet.
Für das Entfernen des privaten Speichers wird eine Liste entfernter Seiten von Seitenrahmenzahlen ähnlich einer Liste freier Seiten eingerichtet, um das Entfernen von Speicher zu unterstützen. Wird zu einem beliebigen Zeitpunkt bestimmt, dass die Seiten nicht online entfernt werden können, kann das System abgeschaltet werden, können die Seiten mit der Konsolen-Software als nicht zugehörig konfiguriert werden und kann die Betriebssystem-Instanz neugestartet werden. Verwendet die Konsole einige oder sämtliche der Seiten im Bereich, verlagert sich die Konsole selbst zu einem anderen Seitensatz. Diese Verlagerung kann auf vielfältige Art und Weise erreicht werden. Beispielsweise kann die Konsole ihre Seiten zu einer weiteren Art von Seiten kopieren, die der Partition zugehörig sind, und anschließend die Ausführung auf den anderen Seitensätzen beginnen. Alternativ kann eine weitere Konsole innerhalb einer weiteren Partition die Partition auflösen, den Bereich der Seiten als "nicht zugehörig" neuzuweisen und anschließend die Partition ohne den Speicher neubilden. Darüber hinaus kann das gesamte System abgeschaltet, der Speicher entfernt und das System neugestartet werden. Der Entfernvorgang kann zu jeder Zeit abgebrochen werden, indem die Seiten von der Liste entfernter Seiten zu den Listen der freien, genullten oder fehlerhaften Seiten bewegt werden.
Befindet sich der Bereich von Seiten, die zu entfernen sind, im privaten Speicher, werden die folgenden Schritte wiederholt, bis sämtliche Seiten entfernt werden können, oder der Entfernvorgang wird abgebrochen. Dieser Vorgang ist im Flussdiagramm von 33A–33B dargestellt. Bevor in den Vorgang eingetreten wird, der im Flussdiagramm von 33–33B gezeigt ist, wird bestimmt, ob es ausreichenden Speicher gibt, um das Entfernen des Speichers zuzulassen. Ein Sys temparameter, wie etwa eine Fließseitenzahl, wird normalerweise verwendet um zu kennzeichnen, dass die Zahl von freiem Speicher bereits verfügbar ist. Ist diese Fließseitenzahl zu gering, d. h. gibt es zu wenige Fleißseiten im System, um das Entfernen einzurichten, wird ein Fehler zum Benutzer zurückgesendet und andernfalls jede Seite im Bereich, der zu entfernen ist, untersucht, wie es in den Schritten beschrieben ist, die in 33A–33B dargestellt sind.
Der Vorgang beginnt bei Schritt 3300 und schreitet von dort zu Schritt 3302 fort, bei dem die erste nicht entfernte Seite innerhalb eines zu entfernenden Seitenbereiches lokalisiert wird. Von Schritt 3302 schreitet der Vorgang zu Schritt 3304 fort, bei dem bestimmt wird, ob die Seite oder die Seiten, die zu entfernen sind, ausstehende Eingangs-/Ausgangs-Vorgänge haben und diese Seiten übersprungen werden; sobald ihre I/O-Vorgänge abgeschlossen sind, können die Seiten für das Entfernen erneut berücksichtigt werden. Haben die Seiten ausstehenden I/O, kehrt der Vorgang zu Schritt 3302 zurück, bei dem die erste nicht entfernte Seite lokalisiert wird, und von dort zu Schritt 3304, wie es zuvor beschrieben wurde. Um es dem System zu gestatten, andere Arbeit durchzuführen, kann es sein, dass das System an diesem Punkt stehen bleibt und darauf wartet, I/O abzuschließen.
Steht bei der momentanen nicht entfernten Seite kein I/O aus, schreitet der Vorgang von Schritt 3304 zu Schritt 3306 fort, bei dem bestimmt wird, ob sich die Seite auf der Liste der freien, genullten, ungeprüften oder fehlerhaften Seiten befindet. Befindet sich eine der Speicherseiten auf einer dieser Listen, wird die Seite von der Liste in Schritt 3308 entfernt und auf der Liste entfernter Seiten angeordnet. Freie Seiten werden zuerst behandelt, so dass kopierte Seiten nicht auf freie Seiten kopiert werden, die ebenfalls Teil des neukonfigurierten Bereiches sind. Von Schritt 3308 schreitet der Vorgang zu Schritt 3326 fort, bei dem bestimmt wird, ob sämtliche Seiten auf der Liste entfernter Seiten plaziert wurden, und wenn dies der Fall ist, schreitet der Vorgang fort, um in Schritt 3328 zu enden. Wenn andererseits sämtliche Seiten nicht auf der Liste entfernter Seiten plaziert wurden, kehrt der Vorgang zu Schritt 3302 zurück und fährt von dort fort, wie es zuvor beschrieben wurde. Sofern dies erwünscht ist, kann es eine Implementierung wählen, die Zahl von Iterationen zu begrenzen und einen Fehlerwiederherstellungsmechanismus ausführen, um einen immerwährenden Kreislauf zu vermeiden.
Gibt es keine Seiten in der Listen der freien, genullten und ungeprüften Seiten, schreitet der Vorgang von Schritt 3306 zu Schritt 3310 fort, bei dem bestimmt wird, ob es Seiten auf der Liste modifizierter Seiten gibt. Gibt es keine Seiten auf der Liste modifizierter Seiten, schreitet der Vorgang zu Schritt 3314 fort. Gibt es andererseits Seiten auf der Liste modifizierter Seiten, schreitet der Vorgang zu Schritt 3312 fort, bei dem die Seiten in einen Sicherungsspeicher, wie etwa eine Systemseitendatei, geschrieben werden. Von Schritt 3312 schreitet der Vorgang zu Schritt 3326 und von dort fort, wie es oben beschrieben wurde. Wenn andererseits der Vorgang von Schritt 3310 zu Schritt 3314 fortgeschritten ist, wird bestimmt, ob beliebige Seiten Vorgangsseiten sind, d. h. Seiten, auf denen eine Applikation läuft. Da jeder Vorgang mehrere Threads haben kann, hat jeder Vorgang seine eigene Tabelle neben anderen Vorgängen. Sind beliebige Seiten Vorgangsseiten, wird eine AST, die einen Mechanismus zur Ausführung innerhalb des Vorgangskontextes bereitstellt, um Zugriff auf die Vorgangseitentabellen zu erhalten, zum Vorgang gesendet, wobei die AST den Vorgang als einzelnen Thread einstellt, sofern dies erforderlich ist, um den Zugriff auf die Tabellenseiten zu synchronisieren. Neue Seitenrahmenzahlen werden für die Seiten zugeordnet und die Inhalte der Seiten zu den neuen Seitenrahmenzahlen kopiert. Die alten Seitenrahmenzahlen werden in Schritt 3316 in der Liste entfernter Seiten der Instanz plaziert. Von Schritt 3316 schreitet der Vorgang zu Schritt 1926 fort und von dort, wie es zuvor beschrieben wurde.
Wird in Schritt 3314 bestimmt, dass keine der Seiten Vorgangsseiten sind, schreitet der Vorgang zu Schritt 3318 fort, bei dem bestimmt wird, ob beliebige der Seiten Teil eines globalen Abschnittes sind, d. h. ein Satz von privaten Seiten, auf die durch zahlreiche Vorgänge gleichzeitig zugegriffen wird. Sind beliebige der Seiten Teil des globalen Abschnittes, schreitet der Vorgang von Schritt 3318 zu Schritt 3320 fort. In Schritt 3320 kann der Name des globalen Abschnittes einem Benutzer angezeigt werden, so dass ein Benutzer bestimmen kann, welche Applikation abgeschaltet werden muss, um Speicher freizugeben. Alternativ kann ein Betriebssystem, das verfolgen kann, wo Seiten abgebildet werden, sämtliche Vorgänge aussetzen, die auf den Abschnitt abgebildet werden, sämtliche Seiten kopieren, sämtliche Vorgangsseiten-Tabelleneinträge modifizieren und die alten Seitenrahmenzahlen auf der Liste entfernter Seiten anordnen. Von Schritt 3320 würde der Vorgang anschließend zu Schritt 3326 und von dort fortschreiten, wie es zuvor beschrieben wurde. Wenn in Schritt 3318 bestimmt wird, dass es keine Seiten gibt, die Teil des globalen Abschnittes sind, schreitet der Vorgang zu Schritt 3322 fort, bei dem bestimmt wird, ob eine beliebige Seite in den Systemadressraum abgebildet wird. Wird keine Seite in den Systemadressraum abgebildet, schreitet der Vorgang von Schritt 3322 zu Schritt 3326 und von dort fort, wie es zuvor beschrieben wurde.
Werden andererseits Seiten in den Systemadressraum abgebildet, schreitet der Vorgang zu Schritt 3324 fort, bei dem jene Seiten, die lediglich gelesen werden, kopiert werden. Sobald sie kopiert ist, wird die Seite in der Liste entfernter Seiten plaziert. Lese-/Schreibseiten werden nur dann kopiert, während sämtliche CPUs innerhalb der Instanz vorübergehend an der Ausführung blockiert sind, so dass sie nicht die Inhalte der Seite ändern. Es wird eine Seite nach der anderen kopiert, und es werden die kopierten Seiten in der Liste entfernter Seiten plaziert. Nach der Migration in Schritt 3324 schreitet der Vorgang zu Schritt 3326 und von dort fort, wie es zuvor beschrieben wurde.
Um gemeinsam genutzten Speicher zu entfernen, wird eine neue Liste von Seitenrahmenzahlen innerhalb jeder Gemeineigenschafts-Partitionsdatenstruktur gemeinsam genutzten Speichers eingerichtet, d. h. innerhalb jeder SHM-CPP-Struktur innerhalb der APMP-Datenbank. Die Liste wird Liste entfernter Seiten der Gemeineigenschafts-Partition genannt. Diese Listen halten vorübergehend Plätze für sämtliche Seiten, die entfernt werden können. Nur wenn sämtliche Seiten innerhalb des 8-MB-Bereiches in der geeigneten Liste entfernter Seiten lokalisiert sind, können die Seiten entfernt werden. Wird zu einem beliebigen Zeitpunkt bestimmt, dass die Seiten nicht entfernt werden können, während der gemeinsam nutzende Satz (der Satz von Instanzen, die Ressourcen, wie etwa Speicher, gemeinsam nutzen) in Betrieb ist, kann der gemeinsam nutzende Satz aufgelöst werden, können die Seiten als nicht zugehörig markiert werden, und kann der gemeinsam nutzende Satz neu gebildet werden. Der Entfernvorgang kann zu einem beliebigen Zeitpunkt abgebrochen werden, indem die Seiten von der Liste entfernter Seiten der Gemeineigenschafts-Partition zur Liste freier Seiten oder fehlerhafter Seiten in Abhängigkeit des vorherigen Zustandes bewegt werden, d. h. zur Liste freier Seiten, sofern sie sich auf der Liste freier Seiten befand, und zur Liste fehlerhafter Seiten, sofern sie sich auf der Liste fehlerhafter Seiten befand.
Der Vorgang des Entfernens gemeinsam genutzten Speichers ist im Flussdiagramm von 34A–34B dargestellt, wobei der Vorgang bei Schritt 3400 beginnt und von dort zu Schritt 3402 fortschreitet, wodurch die erste nicht entfernte Seite im Bereich von Seiten, die entfernt werden solle, lokalisiert wird. Von Schritt 3402 schreitet der Vorgang zu Schritt 3404 fort, bei dem bestimmt wird, ob beliebige Seiten innerhalb des Bereiches von Seiten, die entfernt werden sollen, einen ausstehenden I/O haben. Jene Seiten, die einen ausstehenden I/O haben, werden übersprungen, und der Vorgang kehrt zu Schritt 3402 zurück, um die erste nicht entfernte Seite zu lokalisieren, wie es zuvor beschrieben wurde. Um es dem System zu gestatten, andere Arbeit auszuführen, kann es sein, dass ein System an diesem Punkt stehen bleiben möchte, um auf die Fertigstellung von I/O zu warten.
Haben keine Seiten einen ausstehenden I/O, schreitet der Vorgang von Schritt 3404 zu Schritt 3406 fort, bei dem bestimmt wird, ob beliebige Seiten Teil der APMP-Datenbank sind. Sind beliebige der Seiten Teil der APMP-Datenbank, wird an den Benutzer ein Fehler in Schritt 3408 zurückgesendet. In einem derartigen Fall muss der gemeinsam nutzende Satz mit der APMP-Datenbank auf unterschiedlichen Seiten neu gebildet werden. Dies kann bewerkstelligt werden, indem der gemeinsam nutzende Satz aufgelöst wird, die alten APMP-Datenbankseiten als nicht zugehörig markiert werden, ein neuer Satz von APMP-Datenbankseiten gewählt wird und anschließend der gemeinsam nutzende Satz neu geschaffen wird. Der Vorgang schreitet von Schritt 3408 fort, um in Schritt 3430 zu enden.
Die Zuordnung der Seitenrahmenzahl-Datenbankeintragsseiten, die diese Seiten beschreiben, werden aufgehoben und für die Liste freier Seiten der Gemeineigenschafts-Partition freigegeben, die PMAP-Anordnungen, die gemeinsam genutzten Speicher beschreiben, werden aktualisiert, um die Änderung widerzuspiegeln und die Konsole wird aufgerufen, um die Seite als nicht zugehörig zu markieren. Von Schritt 3428 schreitet der Vorgang anschließend fort, um in Schritt 3430 zu enden. Wenn in Schritt 3426 der Vorgang bestimmt hatte, dass sich sämtliche Seiten nicht auf der Liste entfernter Seiten des gemeinsam genutzten Speichers der Gemeineigenschafts-Partition befanden, kehrt der Vorgang von Schritt 3426 zu Schritt 3402 zurück und schreitet von dort fort, wie es zuvor beschrieben wurde. Wenn in Schritt 3406 der Vorgang bestimmt, dass keine der Seiten Teil der APMP-Datenbank ist, schreitet der Vorgang zu Schritt 3410 fort, bei dem bestimmt wird, ob sich beliebige der Seiten auf der Liste freier, fehlerhafter oder nicht geprüfter Seiten befinden, und wenn dies der Fall ist, werden die Seiten entfernt und in der Liste entfernter Seiten der Gemeineigenschafts-Partition 3412 plaziert. Von Schritt 3412 schreitet der Vorgang zu Schritt 3426, und von dort derart fort, wie es zuvor beschrieben wurde.
Wenn in Schritt 3410 bestimmt wird, dass sich keine der Seiten auf der Liste freier, fehlerhafter oder nicht geprüfter Seiten befindet, schreitet der Vorgang zu Schritt 3414 fort, bei dem bestimmt wird, ob beliebige Seiten Seitenrahmenzahl-Datenbankseiten des gemeinsam genutzten Speichers sind, und wenn dies der Fall ist, schreitet der Vorgang zu Schritt 3416 fort. Vorausgesetzt der Bereich der Seiten enthält in Schritt 3416 nur die Seiten, die innerhalb der Gemeineigenschafts-Partition des gemeinsam genutzten Speichers übrig sind und die sich nicht auf der Liste entfernter Seiten der Gemeineigenschafts-Partition befinden, wird die Gemeineigenschafts-Partition aus der Gemeinschaft entfernt. In Schritt 3416 wird die Gemeineigenschafts-Partition des gemeinsam genutzten Speichers als ungültig markiert, so dass keine Versuche unternommen werden, Seiten von dieser zuzuordnen. Die PMAP-Anordnungen, die gemeinsam genutzten Speicher beschreiben, werden aktualisiert, um das Entfernen des Speichers widerzuspiegeln. Andere APMP-Datenbankstrukturen gemeinsam genutzten Speichers werden aktualisiert, um das Entfernen der Gemeineigenschafts-Partition des gemeinsam genutzten Speichers widerzuspiegeln, wobei die Konsole aufgerufen wird, um die Seiten als nicht zugehörig zu markieren. Wenn die PFN-Datenbankseiten nicht die einzigen Seiten sind, die in der Gemeineigenschafts-Partition gemeinsam genutzten Speichers zurückbleiben, die sich nicht auf der Liste entfernter Seiten befinden, kann alternativ ein Fehler an den Benutzer zurückgegeben werden, wobei in diesem Fall der Benutzer den gemeinsam nutzenden Teil auflösen, die Seiten als nicht zugehörig markieren und den gemeinsam nutzenden Satz neu erzeugen könnte. Um diese Seiten zu kopieren, könnte die Gemeineigenschafts-Partition des gemeinsam genutzten Speichers, die die Seiten enthält, als vorübergehend ungültig markiert werden und die Abbildung der PFN-Datenbankseiten als nur lesen markiert werden. Eine Instanz könnte anschließend die Seiten zu einem neuen Satz von Seiten kopieren, die von der Gemeineigenschafts-Partition zugeordnet werden. Sämtliche Instanzen würden anschließend ihre Abbildungen von der alten Seite zu den neuen Seiten abändern, worauf die alten Seiten anschließend auf der Liste entfernter Seiten der Gemeineigenschafts-Partition plaziert werden könnten. Der Vorgang würde anschließend von Schritt 3416 zu Schritt 3426 und von dort so fortschreiten, wie es zuvor beschrieben wurde.
Wenn in Schritt 3414 bestimmt wird, dass einige Seiten nicht Seitenrahmenzahl-Datenbankseiten des gemeinsam genutzten Speichers sind, würde der Vorgang zu Schritt 3418 fortschreiten, bei dem bestimmt wird, ob beliebige der Seiten Teil eines Bereiches gemeinsam genutzten Speichers sind, der in den Systemraum abgebildet wird, und wenn dies der Fall ist, würde der Vorgang zu Schritt 3420 fortschreiten, bei dem Rückrufroutinen gemeinsam genutzten Speichers aufgerufen und den benutzten Speicher zurückhalten würden, der entfernt werden soll. Die Rückrufroutinen können entweder die Applikation beenden oder einen neuen Bereich gemeinsam genutzten Speichers erzeugen und beginnen, den neuen Bereich zu verwenden. Alternativ oder in Verbindung mit den Rückrufroutinen kann das Etikett des Bereiches gemeinsam genutzten Speichers durch die Konsole angezeigt werden. Dies würde es dem Benutzer gestatten, das Herunterfahren der Applikation zu unterstützen, die den gemeinsam genutzten Speicher verwendet. Von Schritt 3420 würde der Vorgang anschließend zu Schritt 3426 und von dort derart fortschreiten, wie es zuvor beschrieben wurde.
Wenn in Schritt 3418 bestimmt wird, dass keine der Seiten Teil eines Bereiches gemeinsam genutzten Speichers sind, der in den Systemraum abgebildet wird, schreitet der Vorgang zu Schritt 3422 fort, bei dem bestimmt wird, ob beliebige Seiten Teil eines globalen Abschnittes gemeinsam genutzten Speichers sind, d. h. eines Satzes von Abbildungen gemeinsam genutzter Seiten in einen oder mehrere Adressräume eines Vorgangs, so dass sämtliche Vorgänge Zugriff auf dieselben Seiten haben können. Gibt es einige Seiten, die Teil eines globalen Ab schnittes gemeinsam genutzten Speicher sind, schreitet der Vorgang zu Schritt 3424 fort, bei dem eine Rückrufroutine an allen Instanzen aufgerufen wird, deren globaler Abschnitt abgebildet ist. Sämtliche Vorgänge, die auf den globalen Abschnitt abgebildet werden, können ausgesetzt werden, worauf der Code dann sämtliche Daten von einem Seitensatz zu einem weiteren kopieren, sämtliche Vorgangsseiten-Tabelleneinträge abändern, die Datenstrukturen des globalen Abschnittes abändern und die alten Seitenrahmenzahlen in die Liste entfernter Seiten der Gemeineigenschafts-Partition plazieren kann. Alternativ kann jeder Vorgang, der auf den globalen Abschnitt abbildet, benachrichtigt oder abgeschaltet werden, oder es können die Namen der globalen Abschnitte angezeigt werden, so dass der Benutzer bestimmen kann, welche Applikation abgeschaltet werden sollte, um den Entfernvorgang zu unterstützen. Von Schritt 3424 würde der Vorgang anschließend zu Schritt 3426 und von dort derart fortschreiten, wie es zuvor beschrieben wurde.
Um sicherzustellen, dass, wenn I/O für gemeinsam genutzten Speicher initiiert wurde, der Speicher nicht für einen anderen Zweck verwendet wird, bevor wir davon ausgehen können, dass der vollständige I/O im gemeinsam genutzten Speicher abgeschlossen ist, kann eine I/O-Vorrichtung die Instanz unterbrechen, wenn I/O abgeschlossen ist, worauf das System aufzeichnen würde, dass der I/O abgeschlossen ist. Wenn alternativ sämtliche I/O-Busse innerhalb der Partition der Instanz rückgesetzt wurden, ist I/O abgeschlossen. In der SHM_DESC-Struktur im privaten Speicher befindet sich ein Feld mit dem Namen I/O refcnt, das für die I/O-Bezugszahl steht. Es gibt eine SHM_DESC-Struktur je gemeinsam genutztem Speicherbereich.
In der SHM_REG-Struktur in der APMP-Datenbank gibt es eine Bitmaske, die "angefügte Bitmaske" genannt wird. Es gibt lediglich eine SHM_REG-Struktur je gemeinsam genutztem Speicherbereich. Die angefügte Bitmaske enthält ein Bit für jede Instanz im APMP-System. Wenn ein Bit in der angefügten Bitmaske eingestellt ist, wird die entsprechende Instanz an diesem Bereich angefügt.
In der Konfigurationsbaumstruktur, die von der Konsole gewartet wird, gibt es ein ID-Feld im Partitionsknoten, das eingestellt oder gelöscht werden kann, indem eine Konsolen-Rückrufroutine aufgerufen wird. Während des Systemstarts wird nachdem die Partitions-I/O-Busse rückgesetzt wurden, dieses Feld im Partitionsknoten der Instanz gelöscht.
Wenn ein Satz gemeinsamer Nutzung erzeugt wird:

Wenn eine Instanz einem gemeinsam nutzenden Satz beitritt:

1) Stelle das ID-Feld im Partitionsknoten der Instanz auf die momentane ID.

Während des Ausstiegs eines gemeinsam nutzenden Satzes:

Routine shm_reg_decref:

Routine shm_reg_create:

Routine shm_reg_delete:

Eingabe: ID des gemeinsam genutzten Speicherbereiches
Beziehen der SHM_DESC-Adresse im privaten Speicher für diesen Bereich.
Ist das I/O-refcnt-Feld nicht Null, Rücksenden eines Fehlers
Aufheben der Abbildung des gemeinsam genutzten Speicherbereiches
Beziehen der SHM_REG-Adresse im gemeinsam genutzten Speicher für diesen Bereich.
Löschen des Bits in der an SHM_REG angefügten Bitmaske für diese Instanz.
Sind bei der angefügten Bitmaske zusätzliche Bits eingestellt, Rückkehr.
Sind in der an SHM_REG angefügten Bitmaske keine Bits eingestellt:

Routine shmem_APMPDB_recover:

Routine shmem_sharing_set_join:

– Löschen des Bits für diese Instanz in der angefügten Bitmaske

Sind in der angefügten Bitmaske keine weiteren Bits eingestellt

– Aufrufen von shm_reg_delete

(1) Beziehen eines Verweises für den Gemeinschaftsknoten innerhalb des Konfigurationsbaumes
(2) Durchqueren des Konfigurationsbaumes, wobei eine Anordnung gemeinsam genutzten Speichers erzeugt wird. Gibt es keinen gemeinsam genutzten Speicher, Rücksenden eines Fehlers.
(3) Lesen des APMPDB_INFO-Feldes
(4) Ist das APMPDB_INFO-Feld nicht Null Einstellen von PAGES auf APMPDB_INFO Absuchen der Anordnung gemeinsam genutzten Speichers, um sicherzustellen, das sich die Seiten PFN bis PFN+PAGES-1 im gemeinsam genutzten Speicher befinden Befinden sich diese Seiten in der Anordnung gemeinsam genutzten Speichers: Sofern eine geprüfte Speicher-Bitabbildung existiert, Prüfen der Bitabbildung um sicherzustellen, dass diese Seiten nicht als fehlerhaft markiert sind Sind sämtliche Seiten fehlerfrei, Aufrufen von set_APMPDB_INFO, um PFN und PAGES in das APMPDB_INFO-Feld zu schreiben Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, sende PFN und PAGES zum Anrufer zurück Befinden sich beliebige der Seiten nicht im gemeinsam genutzten Speicher oder sind diese fehlerhaft Aufrufen von SET_APMPDB_INFO, um das APMPDB_INFO-Feld zu löschen Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, gehe zu (5), um die APMPDB-Seiten zu wählen
(5) Einstellen von PAGES auf MAX_APMPDB_PAGES
(6) Kreislauf durch die Anordnung gemeinsam genutzten Speichers. Für jedes Element in der Anordnung:
(6.1) Einstellen von PFN auf die niedrigste PFN des gemeinsam Genutzten Speichers im Bereich.
(6.2) Ist eine geprüfte Bitabbildung vorhanden, Prüfen der Bitabbildung um sicherzustellen, dass diese Seiten nicht als fehlerhaft markiert sind
(6.3) Sind sämtliche Seiten fehlerfrei Aufrufen von SET_APMPDB_INFO, um PFN-Seiten in das APMPDB-Feld zu schreiben Sendet SET_APMPDB_INFO einen Fehler zurück, Rückkehr zu (2) Sendet SET_APMPDB_INFO einen Erfolg zurück, sende PFN und PAGES zum Anrufer zurück
(6.4) Werden fehlerhafte Seiten innerhalb des Bereiches angetroffen Stelle PFN auf die höchst numerierte fehlerhafte PFN+1 ein Befindet sich PFN+PAGES-1 weiterhin innerhalb des Anordnungselementes des gemeinsam genutzten Speichers, Rückkehr zu (6.2) Ist PFN+PAGES-1 größer als der Bereich, der von diesem Anordnungselement des gemeinsam genutzten Speichers beschrieben ist, Bewegen zum nächsten Anordnungselement des gemeinsam genutzten Speichers
(6.5) Sind keine Anordnungselemente des gemeinsam genutzten Speichers übrig, Rücksenden eines Fehlers.

Eine beispielhafte Seitenrahmenzahl-Datenbankanordnung ist durch die Speicherabbildung in 21 dargestellt. Bei diesem Beispiel enthält das System zwei Instanzen A und B, jeweils mit 64 Megabyte privaten Speichers und 64 Megabyte gemeinsam genutzten Speichers. Der Speicher ist als 8-kB-Seiten angeordnet, wobei sich der private Speicher für die Instanz A von der Seitenrahmenzahl (PFN) 0 durch PFN 1BFF (hexadezimal) erstreckt. 64 MB gemeinsam genutzten Speichers erstrecken sich von PFN 2000- zu PFN 3FFF. Der private Speicher für die Instanz B erstreckt sich von PFN 800000 durch PFN 801FFF. Der Speicher, der verwendet wird, um die PFN-Datenbank für Instanz A zu halten, kommt aus dem privaten Speicher (0-1FFF) der Instanz A, der Speicher, der verwendet wird, um die PFN-Datenbank für Instanz B zu halten, kommt aus dem privaten Speicher (2000-3FFF) der Instanz B, und der Speicher, der verwendet wird, um die PFN-Datenbank für den gemeinsam genutzten Speicher zu halten, kommt aus dem gemeinsam genutzten Speicher (800000-801FFF). Die Instanz A kann nicht auf die PFN-Datenbankeinträge für den Speicher der Instanz B zugreifen, da, wie es dargestellt ist, dieser Speicherbereich nicht in den Systemraum für die Instanz A abgebildet wird. In ähnlicher Weise kann die Instanz B nicht auf die PFN-Datenbankeinträge für den Speicher der Instanz A zugreifen, da dieser Speicherbereich nicht in den Systemraum für die Instanz B abgebildet wird. Sowohl die Instanzen A und B bilden die gemeinsam genutzten Seiten in die PFN-Datenbankeinträge für den gemeinsam genutzten Speicher ab. Die Instanzen bilden auf die gemeinsam genutzten Seiten mit Privatspeicherseiten-Tabellen ab, weil PFN-Datenbankeinträge privaten Speichers und gemeinsam genutzten Speichers von denselben Seitentabellenseiten abgebildet werden können. Wie es oben erläutert wurde, kann die Granularität des physikalischen Speichers als das kleinste gemeinsame Vielfache einer PFN-Datenbankeintragsgröße und der Speicherseitengröße gewählt werden. Beim dargestellten Beispiel beträgt die Speicherseitengröße 8 kB, wobei die Granularität des physikalischen Speichers gleich der Seitengröße im Quadrat dividiert durch acht (Bytes) oder 8 MB ist. Die Seitengrößen von 16, 32 und 64 kB führen zu einer Granularität des physikalischen Speichers von 32, 128 bzw. 512 MB.
L. WIEDERHERSTELLEN GEMEINSAM GENUTZTEN SPEICHERS IN EINEM MULTIPROZESSORSYSTEM (19–21)
Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden mehrere Instanzen von Betriebssystemen zusammenwirkend auf einem Multiprozessor-Computer ausgeführt, wobei sämtliche Prozessoren und Ressourcen elektrisch miteinander verbunden sind. Die einzelne physikalische Maschine mit mehreren physikalischen Prozessoren und Ressourcen wird durch Software adaptiv in mehrere Partitionen unterteilt, die jeweils die Fähigkeit haben, eine eigene Kopie oder Instanz eines Betriebssystems laufen zu lassen. Jede der Partitionen hat Zugriff auf ihre eigenen physikalischen Ressourcen plus Ressourcen, die als gemeinsam genutzt gekennzeichnet sind. Gemäß einer Ausführungsform wird die Partitionierung von Ressourcen durch Zuweisen von Ressourcen innerhalb einer Konfiguration ausgeführt.
Insbesondere partitioniert die Software logisch und adaptiv CPUs, Speicher und I/O-Ports, indem sie diese zusammen zuweist. Eine Instanz eines Betriebssys tems kann anschließend auf eine Partition geladen werden. Zu unterschiedlichen Zeitpunkten können unterschiedliche Betriebssysteminstanzen auf eine gegebene Partition geladen werden. Diese Partitionierung, die eine Systemverwaltungseinrichtung anweist, ist eine Softwarefunktion; es sind keine Hardware-Grenzen erforderlich. Jede einzelne Instanz hat die Ressourcen, die sie benötigt, um unabhängig ausgeführt zu werden. Ressourcen, wie etwa CPUs und Speicher können dynamisch unterschiedlichen Partitionen zugewiesen werden und von Instanzen von Betriebssystemen verwendet werden, die auf der Maschine laufen, indem die Konfiguration abgeändert wird. Die Partitionen an sich können ebenfalls geändert werden, ohne dass das System neugestartet wird, indem der Konfigurationsbaum abgeändert wird. Das resultierende adaptiv partitionierte Multiverarbeitungs-(APMP-)System weist sowohl eine Skalierbarkeit als auch eine hohe Leistungsfähigkeit auf.
Der Speicher kann in eine oder aus einer Partition oder Gemeinschaft unter Software-Steuerung neukonfiguriert werden, wobei Hardware-Hot-In-Swapping und -Out-Swapping unterstützt sind. Im allgemeinen kann sich der Speicher in einem von drei Zuständen befinden: privat, gemeinsam genutzt oder nicht zugehörig. Der Speicher ist privat, wenn er von einer einzigen Systempartition "besessen" wird. Der Speicher wird gemeinsam genutzt, wenn er einer Gemeinschaft zugehörig ist. Eine Gemeinschaft oder ein gemeinsam nutzender Satz ist eine Sammlung einer oder mehrerer Partitionen, die Ressourcen gemeinsam nutzen können. Andernfalls ist sie nicht zugehörig. Der Speicher kann zwischen einem beliebigen der drei Zustände direkt rekonfiguriert werden. Beispielsweise kann der Speicher aus privat in einer Partition zu privat in einer weiteren Partition oder von gemeinsam genutzt in einer Gemeinschaft zu privat in einer Partition rekonfiguriert werden. Der Speicher wird in einen nicht zugehörigen Zustand durch eine Betriebssysteminstanz und eine Konsolen-Software, die im Systemkonfigurationsbaum widergespiegelt werden, versetzt, bevor der Speicher einem Out-Swapping oder eine In-Swapping unterzogen werden kann. Eine Seitenrahmenzahl-Datenbank ist derart bemessen, dass sie den gesamten möglichen Speicher enthalten kann, der einem In-Swapping unterzogen wird, wobei hinzugefügte Speicherseiten als Seitenrahmenzahl-Datenbankeintragsseiten verwendet werden können. Demzufolge kann neuer Speicher auf einfache Weise aufgenommen werden. Wie es oben beschrieben wurde, muss sich für ein Out-Swapping des Speichers der Speicher im nicht zugehörigen Zustand befinden. Befindet sich der Speicher, der einem Out-Swapping unterzogen werden soll, entweder in einem gemeinsam genutzten oder in einem privaten Zustand, wird er in den nicht zugehörigen Zustand versetzt, um ein Out-Swapping zuzulassen.
Eine Instanz kann einen Bereich gemeinsam genutzten Speichers erzeugen, indem sie dem Bereich die Eigenschaft zuweist, gemeinsam genutzter Speicher zu sein. Der gemeinsam genutzte Speicherbereich kann einer beliebigen Instanz innerhalb desselben gemeinsam nutzenden Satzes wie die erzeugende Instanz angefügt werden. Wenn eine Instanz an einen gemeinsam genutzten Speicherbereich angefügt wird und fehlschlägt, wird der Speicher wiederhergestellt um sicherzustellen, dass die Seiten gemeinsam genutzten Speichers für die nachfolgende Verwendung durch das System verfügbar sind. Ein Instanzfehler kann sich beispielsweise durch Anhalten des Betriebs für eine erweiterte Zeitperiode durch die Instanz, durch das Abstürzen der Instanz oder dadurch zeigen, dass die Instanz anderweitig nicht reagiert. Wenn eine Instanz an einen gemeinsam genutzten Speicherbereich angefügt wird und fehlschlägt, stellt eine weitere Instanz im gemeinsam nutzenden Satz den gemeinsam genutzten Speicherbereich wieder her, indem sie kennzeichnet, dass die fehlerhafte Instanz nicht länger an den gemeinsam genutzten Speicherbereich angefügt ist. Wenn die fehlerhafte Instanz die Synchronisationsverriegelung des gemeinsam genutzten Speicherbereiches hielt und den gemeinsam genutzten Speicherbereich entweder initialisierte oder löschte, wird der gemeinsam genutzte Speicherbereich wiederhergestellt, indem die Seiten gemeinsam genutzten Speichers innerhalb dieses Bereiches freigegeben werden. Wenn die fehlerhafte Instanz die einzige Instanz ist, die an den gemeinsam genutzten Speicherbereich angefügt ist, wird der gemeinsam genutzte Speicherbereich in ähnlicher Weise wiederhergestellt, indem die Seiten gemeinsam genutzten Speichers innerhalb dieses Bereiches wiederhergestellt werden. Gibt es keine weiteren Instanzen innerhalb des gemeinsam nutzenden Satzes, wenn die Instanz fehlschlägt, werden die Seiten gemeinsam genutzten Speichers automatisch wiederhergestellt, wenn der gemeinsam nutzende Satz zu einem späteren Zeitpunkt neu erzeugt wird. Waren Eingang/Ausgang (I/O) an einer beliebigen Seite innerhalb des gemeinsam genutzten Speicherbereiches während des Fehlschlags der Instanz im Fortschritt, verhindert der Mechanismus zur Wiederherstellung des gemeinsam genutzten Speichers eine Beschädigung des gemeinsam genutzten Speichers, indem er sicherstellt, dass die Seiten gemeinsam genutzten Speichers innerhalb des betroffenen gemeinsam genutzten Speicherbereiches nicht von einem weiteren gemeinsam genutzten Speicherbereich freigegeben und erneut verwendet werden, solange es nicht sicher ist, dies zu tun.
Eine Software-Anwendung der oben beschriebenen Ausführungsform kann eine Abfolge von Computeranweisungen enthalten, die auf einem greifbaren Medium, wie etwa einem computerlesbaren Medium, z. B. einer Diskette 142, einer CD-ROM 147, einem ROM 115 oder einer Festplatte 152 von 1 gespeichert sind, oder zu einem Computersystem über ein Modem oder eine andere Schnittstellenvorrichtung, wie etwa einen Kommunikationsadapter 190 übertragen werden können, der mit dem Netzwerk 195 über ein Medium 191 verbunden ist. Das Medium 191 kann entweder ein greifbares Medium sein, das, ohne darauf beschränkt zu sein, optische und analoge Kommunikationsleitungen enthält, oder kann mit Drahtlostechniken implementiert sein, die, ohne darauf beschränkt zu sein Mikrowellen-, Infrarot- oder andere Techniken beinhalten. Es kann zudem das Internet sein. Die Abfolge von Computeranweisungen beinhaltet die gesamte oder einen Teil der Funktionalität, die hier zuvor im Bezug auf die Erfindung beschrieben wurde. Der Fachmann wird verstehen, dass derartige Computeranweisungen in einer Vielzahl von Programmiersprachen für die Verwendung mit zahlreichen Computerarchitekturen oder Betriebssystemen geschrieben sein kann. Zudem können derartige Anweisungen unter Verwendung einer derzeitigen oder zukünftigen Speichertechnologie gespeichert sein, die ohne darauf beschränkt zu sein Halbleiter-, Magnet-, optische oder andere Speichervorrichtungen beinhaltet, oder mit Hilfe einer derzeitigen oder zukünftigen Kommunikationstechnologie gesendet werden, die ohne darauf beschränkt zu sein optische, Infrarot-, Mikrowellen- oder andere Sendetechniken beinhaltet. Es wird in Erwägung gezogen, dass ein derartiges Computerprogrammerzeugnis als entfernbares Medium mit einer beiliegenden gedruckten oder elektronischen Dokumentation, wie etwa als eingeschweißte Software, die auf einem Computersystem beispielsweise in einem System-ROM oder einer Festplatte vorinstalliert ist, vertrieben werden kann, oder von einem Server oder elektronischen Forum über ein Netzwerk, wie etwa das Internet oder das World Wide Web, vertrieben werden kann.

Claims

Computersystem (200) mit einer Vielzahl von zuweisbaren Systemressourcen, enthaltend Prozessoren (108–114), einen Speicher (120) und I/O-Schaltkreise (118), wobei das Computersystem enthält: einen Verbindungsmechanismus (122), der die Prozessoren, den Speicher und die I/O-Schaltkreise derart verbindet, dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einige der I/O-Schaltkreise hat; einen Softwaremechanismus, der die zuweisbaren Systemressourcen einer Vielzahl von Partitionen (202, 204, 206) zuweist, wobei jede Partition wenigstens einen Prozessor, einen Teil des Speichers und einen Teil der I/O-Schaltkreise enthält; eine Instanz eines Betriebssystems (208, 210, 212), das auf jeder Partition (202, 204, 206) läuft; wobei wenigstens eine Gruppe von Partitionen (412, 414) eine Gemeinschaft (410) bildet, die Speicher (434, 448) gemeinsam nutzt; und eine Prozessor-Migrationsvorrichtung, die einen ersten Prozessor aus einer ersten Partition einer zweiten Partition ohne Neustart des gesamten Systems neu zuweist, wobei die Migrationsvorrichtung einen Verarbeitungskontext des Prozessors im Bezug auf die erste Partition vor der Neuzuweisung speichert und nach der Neuzuweisung des ersten Prozessors der erste Prozessor einen beliebigen Verarbeitungskontext lädt, den er während einer vorherigen Ausführung mit der zweiten Partition gespeichert haben kann.
Computersystem nach Anspruch 1, bei dem die Vielzahl der Prozessoren (108–114) physikalisch in Partitionen (202, 204, 206) geteilt ist, und bei dem jede Partition ein Konsolenprogramm (213, 215, 217) enthält, das mit den Prozessoren in der Partition interagiert.
Computersystem nach Anspruch 2, bei dem der Softwaremechanismus zum Zuweisen von Ressourcen ein Konsolenprogramm (213, 215, 217) enthält, das Konfigurationsinformationen hält, die darauf hinweisen, welcher aus der Vielzahl von Prozessoren (108–114), welche Speicherabschnitte (120) und welche I/O-Schaltkreisabschnitte jeder Partition (202, 204, 206) zugewiesen werden; und bei dem der Softwaremechanismus, der die Systemressourcen zuweist, einen ersten Datenspeicher zum Halten von Konfigurationsinformationen, die darauf hinweisen, welcher aus der Vielzahl von Prozessoren jeder Partition zugewiesen wird, und einen Mechanismus enthält, der die Konfigurationsinformationen abändert, um eine Zuweisung der zuweisbaren Systemressourcen von einer Partition zu einer weiteren zu ändern.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch einen Migrationsmechanismus, um zuweisbare Systemressourcen von einer Partition (1000, 1002) zu einer weiteren während des Systembetriebs zu migrieren, ohne das gesamte System neuzustarten.
Computersystem nach Anspruch 4, bei dem der Migrationsmechanismus enthält: einen ersten Kommunikationsmechanismus (904), der mit einer Betriebssystem-Instanz (1008) auf einer Partition (1000) kommuniziert, von der ein Prozessor bewegt wird, um die Betriebssystem-Instanz zu veranlassen, den Prozessor stillzulegen; einen zweiten Kommunikationsmechanismus (910), der mit einer Betriebssystem-Instanz (1018) auf der Partition (1002) kommuniziert, zu der ein Prozessor bewegt wird, um die Betriebssystem-Instanz zu veranlassen, die Verwendung des Prozessors zu beginnen; einen dritten Kommunikationsmechanismus, der mit einer Betriebssystem-Instanz auf einer Partition kommuniziert, von der Speicher bewegt wird, um die Betriebssystem-Instanz zu veranlassen, den Speicher zu entladen; einen vierten Kommunikationsmechanismus, der mit einer Vielzahl von Betriebssystem-Instanzen kommuniziert, die Speicher gemeinsam nutzen, der bewegt werden soll, um die Betriebssystem-Instanzen zu veranlassen, gemeinsam den Speicher zu entladen; und einen fünften Kommunikationsmechanismus, der mit einer Betriebssystem-Instanz auf einer Partition kommuniziert, zu der der Speicher bewegt wird, um die Betriebssystem-Instanz zu veranlassen, das Füllen des Speichers zu beginnen.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch ein erstes Paar von Betriebssystem-Instanzen, die einen ersten Teilsatz der Vielzahl von Betriebssystemressourcen gemeinsam nutzen, und ein zweites Paar von Betriebssystem-Instanzen, die einen zweiten Teilsatz der Vielzahl von Systemressourcen gemeinsam nutzen, der sich vom ersten Teilsatz der Betriebssystemressourcen unterscheidet.
Computersystem nach Anspruch 6, bei dem ein Teil des Speichers für jede Betriebssystem-Instanz im ersten Paar von Betriebssystem-Instanzen bestimmt ist, ein Teil des Speichers für jede Betriebssystem-Instanz im zweiten Paar der Betriebssystem-Instanzen bestimmt ist und ein Teil des Speichers (1124) vom ersten Paar der Betriebssystem-Instanzen und dem zweiten Paar der Betriebssystem-Instanzen gemeinsam genutzt wird.
Computersystem nach Anspruch 7, bei dem der gemeinsam genutzte Teil (1124) des Speichers einen gemeinsam genutzten cache-kohärenten Speicher enthält.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: eine Prozessorkennzeichnungs-Speichervorrichtung, die eine Kennzeichnung speichert, die auf den Betriebszustand eines ersten Prozessors im Bezug auf eine erste Instanz hinweist, wobei die Kennzeichnung von der ersten Instanz verwendet wird, um zu bestimmen, ob der erste Prozessor derzeit für sie für die Verarbeitung von Aktivitäten verfügbar ist.
Computersystem nach Anspruch 9, bei dem die Kennzeichnung ein Speicherbit beinhaltet, das der ersten Instanz zugeordnet ist, wobei eine erste spezielle Einstellung des ersten Speicherbits darauf hinweist, dass der Prozessor von der ersten Instanz gesteuert wird.
Computersystem nach Anspruch 9, bei dem die Prozessorkennzeichnungs-Speichervorrichtung speichert: (A) Kennzeichnungen für jeden einer Vielzahl von Prozessoren, um die Zuordnung jedes Prozessors zu einer der Vielzahl von In stanzen zu definieren, wobei die Kennzeichnungen von der einen Instanz verwendet werden, um zu bestimmen, ob ein gegebener Prozessor derzeit für sie für die Verarbeitung verfügbar ist; (B) einen Satz von Kennzeichnungen für jede Instanz, wobei jeder Satz von Kennzeichnungen seiner jeweiligen Instanz zugeordnet ist und von dieser ausführbar ist und darauf hinweist, welcher der Prozessoren, wenn überhaupt, von seiner entsprechenden Instanz gesteuert wird, und ob ein entsprechender oder entsprechende der Prozessoren einen speziellen Betriebszustand hat/haben, der durch diesen Satz dargestellt ist.
Computersystem nach Anspruch 1, bei dem ein Segment des gemeinsam genutzten Speichers (434, 448) eine Datenbank für den gemeinsam genutzten Speicher der Gemeinschaft bildet um zu darauf hinzuweisen, ob eine Betriebssystem-Instanz, die einer Partition innerhalb der Gemeinschaft zugeordnet ist, aktiv ist.
Computersystem nach Anspruch 12, bei dem jede Instanz innerhalb einer Gemeinschaft auf die Datenbank gemeinsam genutzten Speichers abbildet und jede Instanz die Datenbank gemeinsam genutzten Speichers untersucht, wenn sie auf die Datenbank abbildet, um zu bestimmen, ob andere Instanzen aktiv sind, und sich, sofern andere Instanzen aktiv sind, der Gemeinschaft anschließt.
Computersystem nach Anspruch 13, bei dem der Zugriff auf den Datenbankbereich gemeinsam genutzten Speichers mit Hilfe von Verriegelungen synchronisiert ist, die den Zugriff auf die Datenbank durch eine Instanz sperren, während eine weitere Instanz auf den Bereich zugreift.
Computersystem nach Anspruch 1, bei dem der Softwaremechanismus den Speicher in private (1126, 1128, 1130) und gemeinsam genutzte (1132) Speichersegmente teilt, es nur einer einzigen Partition (1101, 1102, 1104) gestattet, auf jedes private Speichersegment zuzugreifen, und es einer Vielzahl von Partitionen, die eine Gemeinschaft bilden, gestattet, auf jedes gemeinsam genutzte Speichersegment zuzugreifen.
Computersystem nach Anspruch 15, bei dem der Softwaremechanismus den Zugriff durch eine beliebige Partition (1101, 1102, 1104) auf ein beliebiges Speichersegment sperrt, das das Softwaresystem als zu keiner Partition zugehörig kennzeichnet.
Computersystem nach Anspruch 15, bei dem der Softwaremechanismus (A) freie, genullte, ungeprüfte und beschädigte Speicherseitenlisten hält und Speicherseiten, die entfernt werden sollen, auf einen nicht zugehörigen Status abgeändert werden, wenn sie sich auf einer beliebigen der Speicherseitenlisten befinden, (B) eine abgeänderte Seitenliste hält, die auf jene Speicherseiten hinweist, die abgeändert, jedoch nicht in eine Systemseitenerstellungsdatei geschrieben wurden, und (C) eine Datenbank gemeinsam genutzten Speichers innerhalb des gemeinsam genutzten Speichers hält, die darauf hinweist, ob eine Betriebssystem-Instanz, die einer Partition innerhalb der Gemeinschaft zugeordnet ist, aktiv ist.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: eine Fehlerwiederherstellungs-Vorrichtung, die ein Ereignis eines Systemfehlers innerhalb einer ersten Instanz erfasst und in Erwiderung einen Transfer einer Steuerung einer Verarbeitungsressource von der ersten Instanz zur zweiten Instanz ohne Eingreifen der Bedienperson initiiert.
Computersystem nach Anspruch 18, bei dem die zweite Instanz keine Verarbeitungsaufgaben vor dem Fehler innerhalb der ersten Instanz hat und als Unterstützung für die erste Instanz dient, um die Verarbeitungsaufgaben der ersten Instanz zu übernehmen, nachdem der Fehler aufgetreten ist, wobei bei dem Fehler innerhalb der ersten Instanz eine Steuerung für eine Vielzahl von Verarbeitungsressourcen, die der ersten Instanz zugeordnet sind, zur zweiten Instanz übertragen werden und jeder Verarbeitungsressource, für die die Steuerung übertragen werden soll, ein gespeicherter Hinweis auf die Instanz zugeordnet ist, zu der ihre Steuerung übertragen werden soll.
Computersystem nach Anspruch 18, bei dem die Verarbeitungsressource ein sekundärer Prozessor (2408) unter Steuerung der ersten Instanz ist und die erste Instanz zudem einen primären Prozessor (2404) steuert, der den Transfer des Speichers, der von der ersten Instanz gesteuert wird, zu einem gekennzeichneten Abschnitt des Systemspeichers anweist.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: eine Dauerzugehörigkeits-Zuweisungsvorrichtung, die eine Zuweisung einer dauerhaften Zugehörigkeit jedes Prozessors zu einer entsprechenden Partition erzeugt, wobei diese Zuweisungen verwendet werden, um die Prozessoren ihren jeweiligen Partitionen während der Initialisierung (2800) des Systems zuzuweisen.
Computersystem nach Anspruch 21, weiterhin enthaltend eine Temporärzugehörigkeits-Zuweisungsvorrichtung, die eine Zuweisung einer vorübergehenden Zugehörigkeit jedes Prozessors zu einer entsprechenden Partition erzeugt, wobei diese Temporärzugehörigkeits-Zuordnungen auf die Partition hinweisen, die momentan die Steuerung des Prozessors innehat.
Computersystem nach Anspruch 21, weiterhin enthaltend eine Vorrichtung zum Ändern der Dauerzugehörigkeits-Zuweisung eines gegebenen Prozessors, wobei Informationen, die die Zuweisung betreffen, in einem vorbestimmten Speicherplatz gespeichert sind und die Zuweisungsänderungsvorrichtung eine Vorrichtung zum Ändern der Inhalte des vorbestimmten Speicherplatzes beinhaltet.
Computersystem nach Anspruch 22, bei dem die Dauerzugehörigkeits-Zuweisungsvorrichtung die Dauerzugehörigkeits-Zuweisungen mit Hilfe einer speziellen Verarbeitungsaktion durch den ersten Prozessor ausführt, wodurch der erste Prozessor veranlasst wird, einen Speicherort zu prüfen, der Informationen enthält, die für die zugewiesene Zugehörigkeit kennzeichnend sind, und der erste Prozessor veranlasst wird, sobald er sich mit seiner Partition verbunden hat, einen Hinweis auf seine Verfügbarkeit bereitzustellen, an einem SMP-Vorgang teilzunehmen, wobei dieser Hinweis auf die Verfügbarkeit ein Kennzeichen beinhaltet, das durch den ersten Prozessor eingestellt wird.
Computersystem gemäß Anspruch 1, weiterhin enthaltend einen Satz von Hardware-Kennzeichen, die jeder Partition zugeordnet sind, wobei die Hardware-Kennzeichen für eine spezielle Partition wenigstens ein Kennzeichen, dass auf den Betriebszustand eines, speziellen Prozessors hinweist, der auf dieser Partition arbeitet, und ein Verfügbarkeitskennzeichen beinhalten, das darauf hinweist, ob der spezielle Prozessor verfügbar ist, um an einer symmetrischen Mehrfachverarbeitung (SMP) auf dieser Partition teilzunehmen.
Computersystem nach Anspruch 25, bei dem jeder Satz der Hardware-Kennzeichen ein Zugehörigkeitskennzeichen enthält und vor der Neuzuweisung des ersten Prozessors ein erstes der Zugehörigkeitskennzeichen für die erste Partition kennzeichnet, dass der erste Prozessor von einer Instanz gesteuert wird, die auf der ersten Partition läuft, während nach der Neuzuweisung des ersten Prozessors das erste Zugehörigkeitskennzeichen kennzeichnet, dass der erste Prozessor nicht länger von der Instanz gesteuert wird, die auf der ersten Partition läuft, sondern anstelle dessen von einer Instanz gesteuert wird, die auf der zweiten Partition läuft.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: eine Prozessor-Migrationsvorrichtung, die einen ersten Prozessor von einer ersten Partition einer zweiten Partition neu zuweist, während sie unter Steuerung einer Betriebssystem-Instanz, die auf der ersten Partition läuft, einen Hinweis auf die Bestimmungspartition dem ersten Prozessor zuführt und den ersten Prozessor anweist, die Ausführung unter Steuerung der Instanz, die auf der ersten Partition läuft, zu beenden.
Computersystem nach Anspruch 27, bei dem die Vielzahl der Prozessoren in Gruppen unterteilt ist und bei der jede Gruppe ein Konsolenprogramm enthält, zu dem die Steuerung des Prozessors vor dessen Neuzuweisung zur zweiten Partition übertragen wird, und bei dem die Migrationsvorrichtung den ersten Prozessor veranlasst, in einen nicht zugewiesenen Zustand einzutreten, bevor er der zweiten Partition neu zugewiesen wird.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: eine Zwischeninstanz-Kommunikationsvorrichtung, die eine Kommunikation zwischen einer ersten Instanz, die auf einer ersten Partition läuft, und einer zweiten Instanz, die auf einer zweiten Instanz läuft, durch eine Abänderung des gemeinsam genutzten Speichers ermöglicht, auf den beide Instanzen Zugriff haben.
Computersystem nach Anspruch 29, bei dem die Kommunikationsvorrichtung eine gegebene Kommunikation durch Abändern lediglich eines Bits des gemeinsam genutzten Speichers ausführen kann, wobei das Bit, das abgeändert wird, Teil eines Meldungsbitvektors der zweiten Instanz ist und der Meldungsbitvektor eine Vielzahl von Bits enthält, die jeweils einem anderen vorbestimmten Ereignis entsprechen und deren Wert durch die erste Instanz geändert werden kann, um auf das Auftreten des Ereignisses der zweiten Instanz hinzuweisen, und die zweite Instanz die Position des Bits im Bitvektor als Index verwendet, um im Speicher eine geeignete Aufgabe zu lokalisieren, die in Erwiderung der Modifikation dieses Bits initiiert wird.
Computersystem nach Anspruch 30, bei dem die Kommunikationsvorrichtung eine Vorrichtung unter Steuerung der ersten Instanz enthält, die die Erzeugung eines Interrupts von der ersten Instanz zur zweiten Instanz verursacht, um die zweite Instanz darauf hinzuweisen, dass das Bit abgeändert wurde.
Computersystem nach Anspruch 29, bei dem die Kommunikationsvorrichtung weiterhin eine Paketsendevorrichtung enthält, die im gemeinsam genutzten Speicher paketierte Daten speichert, die von der ersten Instanz zur zweiten Instanz übermittelt werden sollen.
Computersystem nach Anspruch 32, bei dem die Kommunikationsvorrichtung für eine gegebene Kommunikation ein Meldungsbit im gemeinsam genutzten Speicher abändert, wobei die Abänderung des Bits die zweite Instanz darauf hinweist, dass das Paket gespeichert wurde, und das System weiterhin eine Vorrichtung enthält, die die Erzeugung eines Interrupts zur zweiten Instanz bewirkt, um die zweite Instanz darauf hinzuweisen, dass das Meldungsbit abgeändert wurde, wobei bei Bestimmung der Gegenwart der paketierten Daten die zweite Instanz ein beliebiges bevorstehendes Datenpaket in den lokalen Speicher kopiert und die Zuordnung des gemeinsam genutzten Speichers aufhebt, in dem es zuvor gespeichert war.
Computersystem nach Anspruch 1, weiterhin gekennzeichnet durch: den Softwaremechanismus, der Speicher privaten Speicherbereichen und gemeinsam genutzten Speicherbereichen zuweist und es einer Vielzahl von Instanzen, die einen gemeinsam nutzenden Satz erzeugen, gestattet, auf einen zugeordneten gemeinsam genutzten Speicherbereich zuzugreifen, indem sie sich an den Bereich anfügen, und einen zweiten Softwaremechanismus zum Wiederherstellen eines gemeinsam genutzten Speichers, an den sich eine fehlerhafte Instanz angefügt hat.
Computersystem nach Anspruch 34, bei dem eine Instanz in einem gemeinsam nutzenden Satz eine weitere Instanz im gemeinsam nutzenden Satz, die als nicht angefügt an einen gemeinsam genutzten Speicherbereich fehlerhaft ist, an den die fehlerhafte Instanz angefügt wurde, zum Zeitpunkt ihres Fehlers markiert, und der Speicher eines gemeinsam genutzten Speicherbereiches freigemacht wird, wenn sich eine letzte Instanz, die an den gemeinsam genutzten Speicherbereich angefügt ist, sich von diesem Bereich löst.
Computersystem nach Anspruch 34, bei dem eine Eingangs-/Ausgangs-Bezugszahl in einem privaten Speicher für jeden gemeinsam genutzten Speicherbereich gehalten wird und (A), wenn ein Eingangs-/Ausgangsvorgang initiiert wird, die Bezugszahl für jede Seite des Speichers im gemeinsam genutzten Speicherbereich, an dem der Eingang/Ausgang ausgeführt wird, in einer Richtung eingestellt wird, und (B), wenn ein Eingangs-/Ausgangs-Vorgang abgeschlossen ist, die Bezugszahl für jede Seite des Speichers im gemeinsam genutzten Speicherbereich, an dem der Eingangs-/Ausgangsvorgang ausgeführt wird, in der entgegengesetzten Richtung eingestellt wird.
Verfahren zum Betreiben eines Computersystems (200), das über eine Vielzahl von zuweisbaren Systemressourcen verfügt, enthaltend Prozessoren (108– 114), einen Speicher (120) und I/O-Schaltkreise (118), wobei das Verfahren folgende Schritte enthält: (a) elektrisches Verbinden der Prozessoren (108–114), des Speichers (120) und der I/O-Schaltkreise (118), so dass jeder Prozessor elektrischen Zugriff auf den gesamten Speicher und wenigstens einen Teil der I/O-Schaltkreise hat; (b) Zuweisen der zuweisbaren Systemressourcen zu einer Vielzahl von Partitionen (202, 204, 206), wobei jede Partition wenigstens einen Prozessor, einen Tei des Speichers und einen Teil der I/O-Schaltkreise enthält; (c) Ausführen einer Betriebssystem-Instanz (208, 210, 212) auf jeder Partition (202, 204, 206); (d) Ausbilden einer Gemeinschaft (420) von Partitionen durch gemeinsames Nutzen von Speicher (434, 448) aus einer Gruppe von Partitionen (412, 414); und Neuzuweisen eines ersten Prozessors von einer ersten Partition zu einer zweiten Partition ohne Neustarten des gesamten Systems, wobei diese Neuzuweisung beinhaltet, dass vor der Neuzuweisung der erste Prozessor veranlasst wird, einen Verarbeitungskontext im Bezug auf die erste Partition zu speichern, und der erste Prozessor nach der Neuzuweisung veranlasst wird, einen beliebigen Verarbeitungskontext zu laden, den er von einer vorherigen Ausführung mit der zweiten Partition gespeichert haben kann.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: (e) Ändern der Konfiguration durch zuweisbare Migrations-Systemressourcen von einer Partition (202, 204, 206) zu einer weiteren Partition während des Systembetriebs ohne ein Neustarten des gesamten Systems (200).
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgende Schritte: (e) Erzeugen eines ersten Paares von Betriebssystem-Instanzen, die einen ersten Teilsatz aus der Vielzahl von Systemressourcen gemeinsam nutzen; (f) Erzeugen eines zweiten Paares von Betriebssystem-Instanzen, die einen zweiten Teilsatz aus der Vielzahl von Systemressourcen gemeinsam nutzen, der sich vom ersten Teilsatz von Betriebssystem-Ressourcen unterscheidet; (g) Bestimmen eines Teils des Speichers für jede Betriebssystem-Instanz im ersten Paar von Betriebssystem-Instanzen; (h) Bestimmen eines Teils des Speichers für jede Betriebssystem-Instanz im zweiten Paar von Betriebssystem-Instanzen; und (i) gemeinsames Nutzen wenigstens eines Teil des Speichers aus dem ersten Paar von Betriebssystem-Instanzen und dem zweiten Paar von Betriebssystem-Instanzen.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgende Schritte: Halten mit jeder Instanz eines Verzeichnisses von Prozessoren, die im System vorhanden sind, und Erkennen einer Vielzahl unterschiedlicher Betriebszustände der Prozessoren im Bezug auf die Instanz; und (f) Speichern in einer Speicher-Speichervorrichtung einer Kennzeichnung für eine erste Ressource, um ihre Zuordnung zu einer ersten Instanz und ihren Betriebszustand im Bezug auf die erste Instanz zu definieren, wobei die Kennzeichnung von der ersten Instanz bei der Ermittlung verwendet wird, ob die erste Ressource verwendet werden soll, und Ändern der Kennzeichnung in einer Art und Weise, die die Verwendung einer Bitmaske beinhaltet, um die Inhalte der Speicher-Speichervorrichtung zu ändern.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: Ausbilden einer Datenbank gemeinsam genutzten Speichers für die Gemeinschaft (420) innerhalb des gemeinsam genutzten Speichers, enthaltend innerhalb der Datenbank gemeinsam genutzten Speichers einen Hinweis darauf, ob eine Betriebssystem-Instanz, die der Gemeinschaft zugeordnet ist, aktiv ist, wobei jede Instanz auf die Datenbank gemeinsam genutzten Speichers abbildet, wenn sie sich der Gemeinschaft anschließt.
Verfahren nach Anspruch 41, bei dem der Schritt (d) folgenden Schritt enthält: Verriegeln der Datenbank gemeinsam genutzten Speichers, um einen Zugriff auf die Datenbank durch eine weitere Instanz zu blockieren, wenn eine Instanz die Datenbank gemeinsam genutzten Speichers untersucht.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: (e) Versetzen des Speichers in einen nicht zugehörigen Zustand, wodurch der Speicher nicht einer beliebigen Partition zugehörig ist, wann immer der Speicher dem System hinzugefügt oder aus diesem gelöscht werden soll.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgende Schritte: Speichen eines Hinweises auf eine Bestimmungs-Instanz, auf die die Steuerung einer ersten Verarbeitungsressource der ersten Instanz bei einem Fehler innerhalb der ersten Instanz übertragen werden soll; Ermitteln bei Auftreten des Fehlers der Bestimmungs-Instanz für die erste Verarbeitungsressource; und Ändern der Indizien einer Steuerung für die erste Verarbeitungsressource, um die Steuerung der ersten Verarbeitungsressource von der ersten Instanz auf die Bestimmungs-Instanz ohne Eingreifen der Bedienperson zu übertragen.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: Bereitstellen einer Zuweisung einer dauerhaften Zugehörigkeit jedes Prozessors zu einer jeweiligen Partition, wobei die Zuweisungen verwendet werden, um die Prozessoren ihren jeweiligen Partitionen während der Initialisierung des Systems zuzuordnen, enthaltend den Schritt des Speicherns von Informationen, die die Zuweisungen im nicht flüchtigen Speicher betreffen.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: Neuzuweisen eines ersten Prozessors von einer ersten Partition zu einer zweiten Partition, wobei die Neuzuweisung beinhaltet, den Prozessor zu veranlassen, einen ersten Verarbeitungszustand vor seiner Neuzuweisung unter Steuerung einer Instanz zu beenden, die auf der ersten Partition läuft.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgenden Schritt: Bereitstellen einer Zwischeninstanz-Kommunikation, die es einer ersten Instanz, die auf einer ersten Partition läuft, mit einer zweiten Instanz zu kommunizieren, die auf einer zweiten Partition läuft, indem gemeinsam genutzter Speicher abgeändert wird, auf den beide Instanzen zugriff haben.
Verfahren nach Anspruch 47, bei dem der Schritt zur Bereitstellung einer Kommunikation folgende Schritte umfasst: Abändern eines Teils eines Meldungsbitvektors der zweiten Instanz, wobei der Meldungsbitvektor eine Vielzahl von Bits enthält, die jeweils einem anderen vorbestimmten Ereignis entsprechen und deren Wert geändert werden kann, um einen Hinweis auf das Eintreten dieses Ereignisses zu geben; und Verwenden der Position des Bits im Bitvektor als Index, um im Speicher eine geeignete Aufgabe zu lokalisieren, die in Erwiderung auf die Abänderung dieses Bits initiiert wird; und Speichern von paketierten Daten im gemeinsam genutzten Speicher, die von der ersten Instanz zur zweiten Instanz übermittelt werden sollen.
Verfahren nach Anspruch 37, weiterhin gekennzeichnet durch folgende Schritte: (e) Zuweisen von Speicher zu einem gemeinsam genutzten Speicherbereich, wodurch eine Vielzahl von Instanzen, die einen gemeinsam nutzenden Satz bilden, Zugriff auf jeden gemeinsam genutzten Speicherbereich haben, indem sie sich an den Bereich anfügen, und Zuweisen von Speicher zu privaten Speicherbereichen; und (f) Wiederherstellen von gemeinsam genutztem Speicher, an den sich eine fehlerhafte Instanz angefügt hat.