Mit der "Enterprise Systems Architecture (ESA) wurde im Bereich der MVS-Großrechner eine neue Runde eingeläutet. ESA ist - daran gibt es keinen Zweifel - die MVS-Systemarchitektur der neunziger Jahre. Amdahl-Systeme werden das komplette Spektrum der ESA-Features unterstützen, die in IBMs einschlägigem "Principles of Operation"-Manual aufgelistet sind. Sie sind damit "noch kompatibler" als die IBM-Mainframes selbst, die in dieser Hinsicht weniger "linientreu" sind, da Benutzern der 3090E-Modelle beispielsweise die optimalen ESA-Features nicht zur Verfügung stehen.
*Stephan Gropp ist bei der Amdahl Deutschland GmbH München, als Systems Engineer bundesweit für den MVS-Support verantwortlich.
Entgegen der atemberaubend schnellen Entwicklung in fast allen Bereichen der Daten- und Informationstechnik ist die Mainframe-Architektur (spätestens) seit der Einführung des IBM-Systems /360 im Jahre 1964 nur ganz selten Gegenstand von Neuerungen gewesen.
Zur Erinnerung: Zum ersten großen Entwicklungssprung weg vom System /360 kam es erst 1972, als das System /370 mit virtuellem Speicherkonzept am Markt erschien. Danach erlebten die Anwender zwar einige Architekturerweiterungen (Stichworte: Realspeicher über 16 Megabyte, dual address space, Serie 3081); ein wirklich neues Konzept aber wurde dann erst wieder im Jahre 1983 mit der extended architecture (XA) aufgelegt. So gesehen ist der Fünfjahresabstand, der zwischen XA und der neuen ESA-Architektur liegt, geradezu kurz.
Warum werden Architekturen geändert? Meistens stecken - vereinfacht gesagt -Engpässe dahinter. So brachte der Umstieg von der /360 auf die /370 den Anwendern eine verfügbare virtuelle Speichergröße von 16 Megabyte und machte sie in diesem Rahmen unabhängig(er) vom Engpaß Realspeicher. Doch auch die 16 Megabyte erwiesen sich nur für eine relativ kurze Zeit als ausreichend; und darum mußte, wollte man größere Datenmengen im virtuellen und im realen Speicher halten können, die Architektur erneut erweitert werden.
Folgerichtig wurde der Grundstein für die extended architecture gelegt. Mit XA wurde zugleich noch ein weiterer Engpaß ausgeräumt: der I/O-Durchsatz. Um ihn zu verbessern, wurde das dynamic channel subsystem aus der Taufe gehoben. Dank XA also blieb dem Mainframe-Anwender eine ganze Zeitlang der Nadelöhr-Streß erspart. Und auch heute noch wird XA von längst nicht jedem Anwender ausgereizt - was auch helfen könnte, die zum Teil zögerliche Aufnahme von ESA im Markt zu erklären.
Geht ESA daher möglicherweise am Bedarf vorbei? Wohl kaum. Die gegenwärtige Situation ist davon gekennzeichnet, daß auf der einen Seite den Anwendern geradezu schwindlig wird vor steigenden MlPS-Zahlen und vor ebenso steigenden Investitionssummen; andererseits davon, daß die Benutzer immer Performance-hungriger werden und ständig mehr CPU-Leistung und l/O-Durchsatz fordern.
Zugleich weiten sich die Einsatzfelder und -formen der EDV unaufhaltsam aus und verlangen nach einer immer größeren Systemvielfalt, die sich mit nur einer oder einigen wenigen Rechnerfamilien nicht abdecken läßt. Man kann eben einen Rennwagen nicht gleichzeitig als Familienkutsche anbieten, selbst wenn man vorher einen schwächeren Motor einbaut.
Vergleicht man die Fortschritte, die die Entwicklungsingenieure in den letzten Jahren im CPU-Bereich und auf dem Gebiet der Plattenspeicher erspielt haben, so stellt sich heraus, daß die CPUs immer leistungsfähiger, "schneller" geworden sind, die Plattenspeicher aber in keiner Weise mithalten konnten. Was aber nützt eine schnelle CPU, wenn das Ein- und Auslagern der Daten genauso langsam vonstatten geht wie seit eh und je?
Gewiß, es gibt auch hier Auswege, etwa in Form von Cache- oder elektronischen Speichern, wie etwa Amdahls "Edas". Doch sind diese Systemkomponenten so kostspielig, daß es sich aus wirtschaftlichen Gründen empfiehlt, nur wirklich Performance-kritische Daten auf ihnen unterzubringen, die restlichen Daten aber auf den herkömmlichen Plattenspeichern zu belassen.
Dem XA-Anwender müssen Durchsatzprobleme keineswegs fremd sein, Hilfe ist insoweit dringend geboten. Diese Hilfe kommt nunmehr in Gestalt von ESA. Sie erfordert - ausgehend von der Erkenntnis, daß der schnellste I/O immer noch der ist, den man gar nicht erst machen muß - eine völlig neue "Philosophie". Und in der Tat geht ESA von dem Grundsatz aus, daß eine gewünschte Information sich bereits dann im Realspeicher beziehungsweise im expanded storage befinden muß, wenn sie benötigt wird.
Die Realisierung dieser Idee geschieht über die sogenannten data spaces. Kannte man bisher lediglich den dual address space (DAS) und damit maximal zwei gleichzeitig ansprechbare Adreßräume, so kann jetzt nicht nur eine Vielzahl von Adreßräumen angesprochen werden; man hat darüber hinaus die Möglichkeit, die Daten in einem oder mehreren Datenräumen von jeweils zwei Gigbyte Größe unterzubringen.
Damit wird verständlich, daß der neuen Philosophie eine Architektur folgen mußte, die die erforderlichen Erweiterungen an Hard- und Software gestatten würde. Mit ESA ist wieder ein Schritt in Richtung auf eine höhere Performance unternommen worden.
Die Amdahl-Rechner der Serien 5890 und 5990 werden von Ende 1989 an ESA unterstützen. Bereits installierte Systeme können kostenlos nachgerüstet werden. Die auf ESA ungerüsteten Systeme sind weiterhin uneingeschränkt kompatibel, Amdahl hat bereits ESA-fähige CPUs angekündigt.
Das wirkliche Interesse der Anwender - dies wird zunehmend erkennbar - konzentriert sich auf Performance-Fragen. Mit Amdahls ESA-Implementation sollte Verschiedenes erreicht werden: Die 5890- und 5990-Großrechner sollten ESA mit allen im IBM-Handbuch "Principles of Operation" aufgelisteten Features unterstützen, gleichzeitig mußte eine exzellente Performance gewährleistet und diese Performance auch für den Systembetrieb unter MDF/ESA sichergestellt sein. MDF ist das multiple domain feature von Amdahl und macht aus einem Großrechner mehrere voneinander unabhängige Systeme, die unterschiedliche Aufgaben erfüllen und mehrere Betriebssysteme gleichzeitig unterstützen können.
Spätestens hier ist der Hinweis angezeigt, daß häufig zu hörende neue Begriffe wie hyperspaces oder system-managed storage zur ESA-Architektur keinen direkten Bezug haben. Zwar ist es richtig, daß ESA nicht nur aus Hardware besteht, doch sind die genannten Features
reine MVS-Komponenten. Hyperspaces etwa befinden sich im erweiterten Speicher und benutzen dieselbe Schnittstelle zum Realspeicher, die auch schon unter XA für das Paging existiert. Hyperspaces könnten mithin auch unter XA ohne Änderung der Hardware laufen; sie wurden nur nicht unter MVS/XA implementiert. Die ESA-Hardware besteht im wesentlichen aus einigen neuen Instruktionen sowie aus der sogenannten advanced address space facility (AASF). AASF wiederum setzt sich aus der neuen access register translation (ART) und den address space facilities (ASF) zusammen. Sind die genannten Features implementiert, so ist eine CPU ESA-fähig. MVS/ESA ist derzeit das einzige Betriebssystem, das diese neue Hardware nutzen kann (siehe Abb. 1).
Wenn Amdahl ausdrücklich alle ESA-Features unterstützt, so hat dies folgende Bewandtnis: Zwar ist die ESA-Architektur in den "Principles of Operation" komplett beschrieben, doch um MVS/ESA auf eine ESA-fähige CPU laden zu können, bedarf es keineswegs der Implementation sämtlicher in den "Principles" aufgeführten Features. Der Preis für "Einsparungen", die man sich an dieser Stelle erlaubt, sind allerdings Performance-Einbußen - für Amdahl Grund genug, kein einziges der beschriebenen Features auszulassen. IBMs 3090E-Modelle laufen im Gegensatz dazu unter ESA ohne die optionalen Features.
PSF, TLB und CSF bei ESA-fähiger CPU
Ein besonders wichtiges der optionalen ESA-Features ist die private space facility (PSF). Diese Facility soll eine ökonomische Ausnutzung des - ebenso wahlfreien - translation lookaside buffer (TLB) weiterhin gewährleisten. Der TLB enthält die jeweils jüngsten Ergebnisse der virtuellen/realen Adreßumrechnungen. Benötigt man also die Realspeicheradresse einer virtuellen Speicherlokation, so sucht die Hardware parallel zur Umrechnungsaktion, ob eventuell die aufwendigen Zugriffe auf die Segment- und Pagetabellen unterbleiben können, weil dieselbe Page bereits vor kurzem angesprochen wurde und sich das Ergebnis daher schon beziehungsweise noch im TLB befindet.
Gewiß: Hätte Amdahl auf den TLB verzichtet, so wäre die Lauffähigkeit der Software davon nicht berührt worden; rund drei Viertel der CPU-Leistung allerdings wären dadurch eingebüßt worden. Da der TLB nicht allzu groß ist, empfiehlt es sich, wo immer möglich, Daten-Belegplatz einzusparen, um ein Maximum an Einträgen gleichzeitig halten zu können. Eine der Möglichkeiten dazu bietet die common segment facility (CSF), die es schon seit /370-Zeiten gibt.
Da die Adressen der common area für alle Adreßräume identisch sind, ist man dank der CSF in der Lage, diese Einträge besonders zu kennzeichnen. Wird nun aus mehreren Adreßräumen dieselbe Page der Common-Area angesprochen, so kann jeder denselben TLB-Eintrag benutzen, und es gibt keine doppelten Einträge.
ESA wirft hier mit seinen Data-Spaces ein neues Problem auf; den solch ein Data-Space kennt keine Common-Area. Weil es nun aber virtuelle Adressen aus der private area eines Data-Space gibt, die innerhalb der Common-Area für Adreßräume liegen, darf man im Falle des Data-Space einen eventuell vorhandenen TLB-Eintrag für die Common-Area nicht benutzen. Dies ist - im wesentlichen - die Aufgabe der PSF (siehe Abb. 2).
Die PSF schafft die Möglichkeit, unter ESA weiterhin die Vorteile der CSF nutzen zu können. Oder anders gesagt: Enthält eine ESA-fähige CPU die PSF nicht, so muß auch auf CSF verzichtet werden. Auch hier wären Performance-Einbußen die Konsequenz. Auf sämtlichen 3090E-Modellen sowie auf den kleineren 3090S-Modellen der IBM fehlt die PSF.
Sämtliche ESA-Instruktionen auf den CPUs
Unangenehm bemerkbar kann sich für den Anwender auch das low address protect feature (LAP) machen. LAP soll verhindern, daß jemand unberechtigterweise die ersten 512 Byte der auf Adresse 0 liegenden prefixed save area (PSA) überschreibt. Ein ESA-Data-Space aber darf volle zwei Gigabyte groß sein, einschließlich der Page 0! Bei einigen CPUs nun tritt LAP dadurch störend in Erscheinung, daß es in den ersten 512 Bytes keinen Update erlaubt.
Die mehr oder minder elegante "Lösung" lautet, beim Anlegen eines Data-Space die Anfangsadresse auf 0 oder 4K zu setzen und damit den Data-Space auf CPUs ohne PSF erst in der zweiten Page anfangen zu lassen. Das rechtfertigende Argument ist, vier Kilobyte Verlust seien bei einer Gesamtgröße von bis zu zwei Gigabyte sicherIich zu verkraften.
Es dürfte sich für sehr viele Anwender jedoch als nachteilig erweisen, ständig mit diesem Offset arbeiten zu müssen: Auf der einen CPU beginnen die Data-Space-Daten auf Adresse 0, auf der anderen X?1000. Dies ist eine gefährliche Fehlerquelle. Dagegen verfügen alle ESA-CPUs von Amdahl über PSF und haben demzufolge weder Schwierigkeiten mit CSF noch mit LAP.
Die meisten der neuen Instruktionen von ESA sind notwendig, um ESA überhaupt betreiben zu können. Zu den Ausnahmen gehören die Instruktionen move with destination key und move with source key. Beide sind im Manual der IBM lediglich als optionale Features aufgeführt, weil das Betriebssystem sie nicht unmittelbar benötigt.
Doch in allen den Fällen, in denen etwa DB2 diese Instruktionen benutzt, ist unbedingt eine CPU erforderlich, die diese Facility implementiert hat. Für Amdahl-Anwender stehen sämtliche Instruktionen auf allen ESA-CPUs zur Verfügung.
Neuartige ALET-Translation für ESA-Hardware
ESA führt die access register translation (ART) neu ein und erreicht damit eine weitere Stufe der virtuellen Adreßumsetzung. In den bisherigen /370- und XA-Systemen beginnt die dynamic address translation (DAT) mit einer Segmenttabelle, die entweder über Control-Register 1 oder über Control-Register 7 aufzufinden war.
Einer der Hauptbestandteile von ESA ist die Möglichkeit, mehrere Adreß- oder Datenräume parallel verarbeiten zu können. Zu diesem Zweck gibt es vier unterschiedliche
Modi, die die notwendigen Segmenttabellen unter ESA auffindbar machen (siehe Tabelle).
Primary- und Secondary-Modus des DAT-Konzepts bleiben erhalten und gewährleisten damit die Aufwärtstompatibilität. Der Begriff home mode erfuhr unter ESA eine Modifikation dahingehend, daß man ihm mit CR13 nun ein eigenes Control-Register zugewiesen hat. Um aber mehrere Adreß- oder Datenräume gleichzeitig adressieren zu können, muß man sich im Access-Register-Modus befinden, der den Pointer (Hinweisadresse) auf eine Segmenttabelle über eines der 16 neuen Access-Register findet. Die Access-Register sind also ausschließlich in diesem Modus von Bedeutung.
Die Access-Register sind fest verbunden mit den 16 herkömmlichen General-Purpose-Registern. Wenn mithin bei der Adreßumsetzung im Access-Register-Modus ein Basisregister zur Bildung einer virtuellen Adresse angesprochen wird, adressiert man gleichzeitig das dazugehörige Access-Register (siehe Abbildungen 3 und 4). Dieses Register enthält den sogenannten access list entry token (ALET), über den letztlich ein segment table descriptor (STD) - dies ist ein Pointer auf eine Segmenttabelle - gefunden werden kann. Darum muß sich in der ESA-Hardware eine neuartige ALET translation befinden, die nun zunächst die Aufgabe hat, den jeweiligen STD zu ermitteln, der dann seinerseits als Eingabe zur altbewährten DAT benutzt werden kann.
Von einer eingehenden Erläuterung der ALET-Translation muß hier aus Platzgründen abgesehen werden; sie ist im Bedarfsfall in den "Principles of Operation" nachzulesen. Es dürfte auch ohne eine solche Darlegung klargeworden sein, daß man auf keinen Fall bei jeder Adreßumrechnung den gesamten ALET-Translation-Prozeß durchlaufen darf, wenn man im Access-Register-Modus eine vernünftige Performance erreichen will.
ALB für die Performance steigert die Effizienz
Aus diesem Grunde werden die Ergebnisse der jeweils letzten Umrechnungsprozesse in dem neuen ART lookaside buffer (ALB) abgelegt. Um einen STD zu finden, wird nun gleichzeitig die ALET-Translation und ein ALB lookup durchgeführt - ein Verfahren, das stark an den obenbehandelten TLB erinnert.
Zwischen der ESA-Performance und der Effizienz der ALB-Algorithmen gibt es einen unmittelbaren Zusammenhang! Dieser Hinweis ist deshalb bedeutsam, weil der Anwender derzeit in aller Regel davon noch nichts merkt. Grund: Noch gibt es kaum Applikationen, die den Access-Register-Modus benutzen. Vielen Anwendern würde es derzeit darum überhaupt nicht auffallen, wenn ihre CPU völlig ohne ALB operierte.
So kann es sein, daß ein Anwender mit seinen beiden von unterschiedlichen Herstellern stammenden ESA-CPUs gegenwärtig durchaus noch gleichhohe Performance-Werte erzielt. Innerhalb eines Jahres dürfte dieses Bild sich grundlegend gewandelt haben. Denn mittlerweile kommen sukzessive die Softwareprodukt-Releases auf den Markt, die vom Access-Register-Modus Gebrauch machen.
Parallel dazu steigt die Benutzung des ALB an. Da der ALB aber eine deutliche Effizienzsteigerung bewirkt, ist davon auszugehen, daß die mit einer guten ALB-lmplementation ausgestattete CPU ihre gute Performance beibehalten wird, eine andere jedoch nicht. Derartige Performance-Unterschiede sind übrigens auch dann zu erwarten, wenn das Leistungsverhalten unterschiedlicher CPUs desselben Herstellers im Zeitablauf beobachtet wird. So ist der ALB, den Amdahl für die Modellreihen 5890 und 5990 implementiert hat, nicht identisch.
Wie kommt es, daß ein Hersteller bei der ALB-Entwicklung derart viele Freiheiten hat? Der Grund ist der gleiche, der auch schon für den TLB galt: Die Architekturbeschreibung sagt über beide Features nichts aus. Aufgeführt wird lediglich die neue purge ALB-lnstruktion (PALB); doch ALB wie auch TLB sind prinzipiell nicht notwendig, um ESA zu betreiben. Unter Performance-Aspekten allerdings ist - wie dargelegt - ihre Existenz zwingend notwendig.
Der ALB wird zweistufig implementiert
Es lohnt sich, einen Blick auf Amdahls ALB-Design zu werfen. Zwei Arten von ALETs (und damit Inhalte der Access-Register) werden unterschieden: Die spezial ALETs entsprechen den Hex-Werten 0,1 und 2, die direkt auf die Control-Register 1,7 und 13 verweisen. Diese ALETs stellen einen fast path in der ALET-Translation dar und kosten keinen Overhead auf Amdahl-CPUs, das heißt ein Special-ALET im Access-Register-Modus wird genauso schnell verarbeitet wie etwa das Control-Register 1 im Primary-Modus.
Im Gegensatz dazu muß der übliche ALET-lnhalt zunächst von der ALET-Translation verarbeitet werden. Die ESA-Performance wird in Zukunft immer mehr davon abhangen, a) wieviele ALET-Translations durchgeführt werden müssen und b) wie gut die ALET-Translation funktioniert.
Das Ergebnis einer ALET-Umsetzung wird im ALB gespeichert, da davon auszugehen ist, daß die aktuell ablaufende Anwendung mehr als einmal diesen Adreß- beziehungsweise Datenraum ansprechen wird. Wird also derselbe ALET ein zweites Mal zur Ermittlung der Segmenttabelle benutzt, so kann der STD dem ALB entnommen werden.
Amdahls ALB-Implementation ist zweistufig. Unterschieden wird zwischen "aktiven" und "zuletzt benutzten" ALETs. Die aktiven ALETs entsprechen den momentanen Inhalten der Access-Register. Die Amdahl-Rechner 5890 und 5990 enthalten einen zusätzlichen Satz von Registern, nämlich die sogenannten STD-Register, die wiederum mit den Access-Registern, fest verknüpft sind. Die STD-Register speichern das Umrechnungsergebnis des dazugehörigen Access-Registers; und solange der Inhalt eines Access-Registers sich nicht ändert, kann unmittelbar der Wert des STD-Registers benutzt werden, um die Segmenttabelle zu finden.
Dies erspart die Suche nach diesem Wert im ALB. Immer wenn der Inhalt des STD-Registers benutzt wird, ist der Ablauf ebenso schnell wie beim Special-ALET. Wenn also ein Programm zu Beginn seine Access-Register lädt und sie anschließend nicht mehr ändert, kann es ohne jeglichen zusätzlichen ART-Overhead seine weiteren Data- und Adress-Spaces ansprechen.
Hoher Instruktionsdurchsatz durch Trennung von Operanden
Sobald ein Access-Register mit einem anderen Wert geladen wird, wandert der "alte" Eintrag in den ALB. So bleibt diese Information weiterhin erhalten und erspart somit eine komplette Access-Register-Translation. Erst dann, wenn der ALB vollgeschrieben ist, oder wenn das Betriebssystem eine PALB-Instruktion ausführt, geht diese Information verloren. Daher ist die Größe des ALB für die ESA-Performance von großer Wichtigkeit. Allerdings. Über Größe und Aufbau des ALB ist wie schon erwähnt, nirgendwo etwas festgelegt; und deshalb wird man entsprechend viele unterschiedliche Implementationen bei den diversen CPU-Typen vorfinden.
Zur Verdeutlichung eine Übersicht über die einzelnen Verknüpfungen: Der Ablauf der ALET-Translation ist der Abb. 5 zu entnehmen.
Ein weiterer wichtiger Aspekt des Themas "ESA-Performance auf Amdahl-CPUs" ist die beim high speed buffer (HSB) vorgenommene Trennung zwischen Instruktionen und Operanden: Der HSB kann von Speicherinhalten, die aufgrund von Operanden adressiert wurden, nicht überlagert werden. Dieses Design, das bisher schon ausschließlich in Amdahl-Maschinen zu finden war, dürfte sich unter ESA erst recht vorteilhaft auswirken.
Gerade bei Datenbewegungen in Data-Spaces sind typischerweise große Datenmengen - beispielsweise ganze Lademodule - im Spiel; das heißt, es erhöht sich gerade dann die Wahrscheinlichkeit, daß die nächste auszuführende Instruktion im HSB überschrieben wird. Die Konsequenz davon wäre ein niedriger Instruktionsdurchsatz - und genau dieser kann sich weder auf der 5890 noch auf der 5990 ereignen.
Jede Domain hat ihren eigenen ALB
Als drittes Ziel seiner ESA-lmplementierungsarbeiten hatte Amdahl sich vorgenommen, die volle Performance auch beim Systembetrieb unter MDF/ESA zu gewährleisten. Das Motiv dazu lieferte die Beobachtung, daß das multiple domain feature in den zurückliegenden Jahren immer mehr an Bedeutung gewonnen hat und die Anwender auch unter ESA nicht auf diese Annehmlichkeit verzichten wollen. Wie gesagt: MDF teilt einen physischen Rechner in mehrere logische auf. Daher können mehrere Betriebssysteme nebeneinander und unabhängig voneinander ablaufen.
Amdahl wollte jedoch nicht nur die Performance unter dem MDF/ESA uneingeschränkt sicherstellen; dem MDF-Benutzer sollten auch sämtliche ESA-Features geboten werden. Darum ist an dieser Stelle nochmals auf den ALB einzugehen. Die interne Implementation des ALB ist für die beiden Rechnerserien 5890 und 5990 zwar unterschiedlich, jedoch in beiden Fällen domainspezifisch. Das bedeutet: Jede Domain wird ihren eigenen ALB haben.
Dies hat unmittelbare Auswirkungen auf die purge ALB-Instruktion: Muß nämlich in einer Domain die PALB-Instruktion ausgeführt werden, so werden nur diejenigen Einträge im ALB gelöscht, die zu dieser Domain gehören. Die ALB-Einträge der anderen Domains aber bleiben davon unberührt.
ESA-Upgrade für 5890- und 5990-User kostenlos
Unabdingbares - und letztlich auch erreichtes - Ziel war es, vom ersten Tag an kontinuierlich eine hohe Performance zu gewährleisten, und zwar unabhängig von den Softwareprodukten, die die einzelnen ESA-Features mal mehr, mal weniger in Anspruch nehmen.
Hingewiesen sei auch noch darauf, daß der Schulungsaufwand, der mit der Implementierung von ESA auf den Anwender zukommt, vernachlässigbar gering ist; er ist nicht höher als bei jedem normalen Releasewechsel.
Amdahl wird den ESA-Upgrade sowohl für die 5890- als auch für die 5990-Anwender kostenlos zur Verfügung stellen. Seit April 1989 laufen in Sunnyvale/Kalifornien bereits die ersten Maschinen im Testbetrieb unter ESA. Die offizielle Verfügbarkeit von ESA ab dem vierten Quartal 1989 ist sichergestellt.