@database doc/VMM.guide @Node Main "VMM/doc/VMM.guide" @Next "COPYRIGHT" VMM (Virtual Memory Manager für Amigas mit MMU) Benutzeranleitung Version 3.3a $Date: 96/07/24 20:29:26 $ von Martin Apel email: apel@tecmath.de CONTENTS 0. @{" Shareware-Hinweis " Link "COPYRIGHT"} 1. @{" Einführung " Link "INTRODUCTION"} 2. @{" Voraussetzungen " Link "REQUIREMENTS"} 3. @{" Installation " Link "INSTALLATION"} 4. @{" Änderungen " Link "CHANGES"} 5. @{" Das Einstellungssfenster " Link "VMMPREFS"} 6. @{" Prozessorunterschiede " Link "PROC_DIFFS"} 7. @{" Schwierigkeiten " Link "PROBLEMS"} 8. @{" Häufig auftretende Probleme" Link "TROUBLESHOOTING"} 9. @{" Technische Beschreibung " Link "TECHNICAL_DES"} 10. @{" VMM.library " Link "VMM_LIBRARY"} 11. @{" Externe Programme " Link "EXT_PROGS"} 12. @{" Bekannte Fehler " Link "KNOWN_BUGS"} 13. @{" Fehlermeldungen " Link "BUG_REPORTING"} 14. @{" Danksagungen " Link "ACKNOWLEDGMENTS"} 15. @{" Verschiedenes " Link "MISCELLANEOUS"} @EndNode @Node "COPYRIGHT" "VMM/doc/VMM.guide/COPYRIGHT" @Next "INTRODUCTION" @Prev "Main" @Toc "Main" Ich habe entschieden, VMM zu Shareware zu machen. Ich habe ungefähr zwei Jahre mit der Entwicklung von VMM verbracht und es gibt scheinbar eine Menge Leute, die es verwenden. Daher habe ich mich für die folgende Vereinbarung entschieden: Sie können VMM für 30 Tage testen, um herauszufinden, ob es für Ihre Ansprüche einsetzbar ist. Wenn Sie VMM dauerhaft einsetzen, bitte ich Sie, VMM zu registrieren. Die Registrierungsgebühr beträgt 30 DM, 20 US-$ oder den gleichen Betrag in anderer Währung. Es gibt keine extra registrierte Version, die vorliegende Version von VMM beinhaltet alle Fähigkeiten. Sie können mir Bargeld schicken oder eine Überweisung auf mein Konto durchführen. Meine Adresse und Bankverbindung finden Sie unter @{"Verschiedenes" Link "MISCELLANEOUS"}. Registrierte Benutzer werden von mir bei jeder neuen Version benachrichtigt, falls mir eine E-Mail Adresse von Ihnen zur Verfügung steht. WIHTIG: Das Urheberrecht dieses Programms liegt bei Martin Apel, es kann jedoch frei verteilt werden, vorausgesetzt, die folgenden Regeln werden beachtet: - Weder das Programm noch die beiliegende Dokumentation dürfen in irgendeiner Weise verändert werden. - Dieses Archiv darf nur in vollem Umfang weitergegeben werden. - Eine Verteilung von VMM darf auf beliebigem Wege erfolgen, es darf jedoch nur eine geringe Gebühr für Kopieren, Medienkosten und Versand erhoben werden. - Einfügen in Software-Bibliotheken wie Fish Disks ist erlaubt, falls die Gebühren denen für Fish-Disks entsprechen. - Das Programm darf nicht ohne die schriftliche Zustimmung des Authors kommerziell vertrieben werden. Durch Kopieren, Verteilung und Benutzung des Programms erklärt sich der Benutzer mit den obigen Regeln einverstanden. @EndNode @Node "INTRODUCTION" "VMM/doc/VMM.guide/INTRODUCTION" @Next "REQUIREMENTS" @Prev "COPYRIGHT" @Toc "Main" 1. EINFÜHRUNG Sogar auf dem A4000 mit 6 MB habe ich mich manchmal nach mehr Speicher gesehnt, oder alternativ nach virtuellem Speicher. Da der 68040 eine MMU enthält und ich daran interessiert war, wie sie funktioniert, habe ich selbst einen virtuellen Speichermanager geschrieben. Dieser emuliert bis zu 512 MB virtuellen Speicher in einer vom Benutzer konfigurierbaren Menge physikalischen Speichers. Ab Version V3.3 unterstützt VMM alle 680x0 Prozessoren mit einer MMU, selbst den 68060. Das Auslagern von Seiten (Paging) kann auf eine Partition, eine Datei oder eine sogenannte Pseudo-Partition erfolgen, die die Geschwindigkeit einer eigenen Partition mit der Flexibilität einer Datei verknüpft. Siehe @{"Änderungen von V3.2 zu V3.3" Link "To_3_3"} für eine Beschreibung neuer Funktionen. Was bedeutet virtueller Speicher? In einem System mit virtuellem Speicher muß der Prozessor jede Adresse, die er verwendet, erst in eine physikalische Adresse übersetzen. Diese Übersetzung wird in Hardware von der Speicherverwaltungseinheit (MMU) für jeden Speicherzugriff durchgeführt. Der physikalische Speicher wird in sogenannte Kacheln gleicher Größe aufgeteilt; VMM verwendet eine Seitengröße von 4 oder 8 KB. Eine Seite kann sich entweder im Hauptspeicher oder auf der Festplatte befinden. Wenn ein Zugriff auf eine ausgelagerte Seite erfolgt, wird ein Seitenfehler ausgelöst. VMM hält den Prozeß, der den Seitenfehler verursacht hat, an und lädt die benötigte Seite irgendwo in den Hauptspeicher. Danach kann der Prozeß mit seiner Arbeit fortfahren. Von diesem Vorgang merkt der Prozeß nichts, außer daß dieser eine Speicherzugriff erheblich länger als normal dauert. Für genauere Informationen zum Thema virtuelle Speicherverwaltung seien folgenden Bücher empfohlen (Englisch): Operating systems - Design and implementation Andrew Tanenbaum Prentice Hall Operating system concepts Silberschatz, Galvin Addison Wesley Wie stellt VMM virtuellen Speicher auf dem Amiga bereit? Leider unterstützt das Amiga-Betriebssystem keinen virtuellen Speicher, daher ist VMM in gewisser Weise ein Hack. Ich habe versucht, alles so systemkonform wie möglich zu halten, aber es gibt bestimmte Situationen, in denen VMM einen Systemcrash hervorruft. Dies liegt nicht an VMM, sondern an der Gedankenlosigkeit der Amiga-Entwickler bzgl. virtuellen Speichers. VMM installiert eine normale Speicherliste in ExecBase, sodaß virtueller Speicher genauso wie normaler Speicher behandelt wird. Es wird nur dann virtueller Speicher allokiert, wenn das MEMF_PUBLIC bei einer Anforderung nicht gesetzt ist. Sonst könnte es passieren, daß Systemdaten wie Taskkontrollblöcke oder IORequests ausgelagert würden, was zu einem Absturz führen würde. Zusätzlich gibt es einen Mechanismus für Programme, die unter normalen Umständen mit VMM abstürzen würden. Ab V3.0 kann auch Programmcode in den virtuellen Speicher verlegt werden. @EndNode @Node "REQUIREMENTS" "VMM/doc/VMM.guide/REQUIREMENTS" @Next "INSTALLATION" @Prev "INTRODUCTION" @Toc "Main" 2. VORAUSSETZUNGEN VMM benötigt eine funktionierende MMU. Stellen Sie sicher, daß Ihr Prozessor eine MMU enthält, ein EC-Typ des Prozessors wird nicht mit VMM zusammenarbeiten. Es gibt leider keinen zuverlässigen Weg herauszufinden, ob eine funktionsfähige MMU vorhanden ist, da Motorola ihre Prozessoren mit Defekten in der MMU als EC-Typen verkauft. Es kann also passieren, daß die MMU auf den ersten Blick funktioniert, aber unter bestimmten Bedingungen Fehler besitzt. Außerdem sollten Sie eine Festplatte besitzen, obwohl es theoretisch möglich ist, auf jedes beliebige blockorientierte Gerät auszulagern. Es sollten auch mindesten 2 MB Hauptspeicher vorhanden sein. Als Betriebssystem benötigt VMM mindestens Version 2.0. Ab V2.1 können Sie auch die Vorteile verschiedener Sprachunterstützung genießen. Für die Benutzerschnittstelle wird mindesten MUI 2.3 (V10) benötigt. @EndNode @Node "INSTALLATION" "VMM/doc/VMM.guide/INSTALLATION" @Next "CHANGES" @Prev "REQUIREMENTS" @Toc "Main" 3. INSTALLATION Zur Installation gibt es ein Installer-Skript, das die nötige Arbeit durchführt. Klicken Sie auf das Icon auf der Workbench und Sie werden durch den Installationsvorgang geführt. Die Installation fragt Sie nach der Seitengröße, die Sie verwenden wollen. Normalerweise ist eine Seitengröße von 4 KB zu empfehlen, es gibt jedoch einige Fälle, in denen nur die 8 KB-Version bei Ihnen korrekt arbeitet (z.B. bestimmte 68040-Karten für den A2000). Eine Seitengröße von 8 KB kann schneller sein, falls Sie viel mit Bildbearbeitungsprogrammen arbeiten. Wenn Sie das erste Mal VMM benutzen, müssen Sie einige Parameter in der Benutzeroberfläche einstellen. Dies können Sie tun, indem Sie VMM von der Workbench oder vom CLI aus starten. Eine Standardkonfiguration ist vorhanden. Nachdem Sie Ihre Einstellungen durchgeführt haben, können Sie die Tooltypes im Icon zu "CX_POPUP=NO" ändern, damit VMM nicht bei jedem Start sein Fenster öffnet. Zur Laufzeit können Sie dieses Fenster jedoch jederzeit über den Hotkey (Standard: ralt rshift v) öffnen. Alternativ können Sie VMM einfach ein zweites Mal starten. Die folgenden Parameter können als Tooltypes oder als Parameter im CLI angegeben werden: CX_POPUP=YES|NO CX_PRIORITY= CX_POPKEY= SETTINGS= andere Einstellungsdatei verwenden QUIT VMM verlassen FORCE Dies verhindert VMM Nachfrage beim Überschreiben einer anderweitig genutzten Partition, z.B. für LINUX @EndNode @Node "CHANGES" "VMM/doc/VMM.guide/CHANGES" @Next "To_1_1" @Prev "INSTALLATION" @Toc "Main" 4. ÄNDERUNGEN @{" Änderungen von V1.0 zu V1.1" Link "To_1_1"} @{" Änderungen von V1.1 zu V1.2" Link "To_1_2"} @{" Änderungen von V1.2 zu V1.3" Link "To_1_3"} @{" Änderungen von V1.3 zu V2.0" Link "To_2_0"} @{" Änderungen von V2.0 zu V2.1" Link "To_2_1"} @{" Änderungen von V2.1 zu V3.0" Link "To_3_0"} @{" Änderungen von V3.0 zu V3.1" Link "To_3_1"} @{" Änderungen von V3.1 zu V3.2" Link "To_3_2"} @{" Änderungen von V3.2 zu V3.3" Link "To_3_3"} @{" Änderungen von V3.3 zu V3.3a" Link "To_3_3a"} @EndNode @Node "To_1_1" "VMM/doc/VMM.guide/To_1_1" @Prev "CHANGES" @Next "To_1_2" @Toc "Main" Änderungen von V1.0 zu V1.1: - VMM lagerte bei Systemen mit mehreren Festplatten immer auf die Platte mit Unit 0 aus. - Es gibt jetzt eine dynamische Allokationsstrategie für Kacheln. VMM allokiert bei einem Seitenfehler eine neue Kachel falls möglich, um Festplattenzugriffe zu sparen. Wenn dieser Speicher für andere Zwecke benötigt wird, wird dieser von VMM wieder freigegeben. - Auslagerung auf Datei. Dies ist leider relativ langsam aufgrund des hohen Overheads des Amiga-Dateisystems. - VMM sollte jetzt auf allen echten 68040-Prozessoren problemlos laufen. Bei Bedarf wird eine eigene MMU-Tabelle installiert. - Das Statistik-Fenster in nun Font-sensitiv und stellt mehr Informationen über den Auslagerungsprozeß dar. Zusätzlich gibt es ein Programm "VMMStat", sodaß das Statistikfenster nicht die ganze benötigt wird. - Bis zu 64 MB virtueller Speicher werden nun unterstützt. - Es gibt zwei verschiedene Programmversionen für Seitengrößen von 4 und 8 KB. - Die Zugriffszeit auf die Platte wurde reduziert, indem die Kopfbewegungen minimiert werden. @EndNode @Node "To_1_2" "VMM/doc/VMM.guide/To_1_2" @Prev "To_1_1" @Next "To_1_3" @Toc "Main" Änderungen von V1.1 zu V1.2: - Aus Sicherheitsgründen wurde es in V1.1 Tasks verboten, bei gesetztem Forbid() virtuellen Speicher zu allokieren. Dies wurde wegen Problemen mit AdPro rückgängig gemacht. - Es gibt jetzt eine Programm "ShowPageSize", daß die möglichen Seitengrößen für ein gegebenes System ermittelt. - Fehler behoben, der zu merkwürdigen Fehlern führte, falls der Name der Auslagerungsdatei oder der Auslagerungspartition länger als 20 Zeichen war. Die maximale Pfadlänge beträgt nun 80 Zeichen. - Die maximal verfügbare Menge virtuellen Speichers wurde nach Anfrage auf 128 MB angehoben. - Es wurde eine spezielle Bibliothek zu VMM hinzugefügt, die es nur dafür geschriebenen Programmen ermöglicht, virtuellen Speicher zu nutzen. Es gibt Funktionen wie AllocVMem, FreeVMem und AvailVMem. Siehe vmm_lib.doc. @EndNode @Node "To_1_3" "VMM/doc/VMM.guide/To_1_3" @Prev "To_1_2" @Next "To_2_0" @Toc "Main" Änderungen von V1.2 zu V1.3: - FreeMem markiert freigegebene Seiten jetzt als leer, um das Auslagern unbenutzter Seiten beim Freigeben des Speichers zu vermindern. Leider werden dadurch Tools wie Mungwall behindert, die Speicher beschreiben, den sie nicht allokiert haben. - Fehler behoben, der ein merkwürdiges Verhalten während Festplattenzugriffen verursachte, deren Units das gleiche Device verwenden. Vermutlich war dies für Probleme mit der Grafikausgabe von Text und Icons verantwortlich. - Das Statistikfenster ist jetzt "zoombar", sodaß nur die Titelzeile zur Anzeige des freien virtuellen Speichers sichtbar ist. Position und Anfangszustand können konfiguriert werden. - Die Einstellungen können jetzt verändert werden, während VMM läuft. Alle Parameter außer der Auslagerungspartition/-datei, deren Größe und der Position des Statistikfensters werden jetzt sofort geändert. - Es gibt nun eine "fortgeschrittene" Einstellmöglichkeit für die Speicherallokation in VMMPrefs. Man kann jetzt für jede Task die minimale Größe der VM-Allokationen für PUBLIC und nicht-PUBLIC-Speicher getrennt einstellen. - Anzahl der Signale, die eine Task während eines Seitenfehlers benötigt, reduziert. Vorher gab es Probleme mit Tasks, die all ihre Signale selbst benötigten. - Die Wait-Funktion wurde gepatcht, um Probleme mit Tasks zu umgehen, deren Stack im virtuellen Speicher liegt. - VMM kann nun verlassen werden, selbst wenn noch virtueller Speicher allokiert ist. In diesem Fall lädt VMM alle noch in Gebrauch befindlichen Seiten in den Hauptspeicher und modifiziert die MMU-Tabelle entsprechend. Anschließend wird das Programm verlassen. - Modifizierte Seiten werden geschrieben, bevor dies unbedingt nötig ist. Dies reduziert die mittlere Zeit für einen Seitenfehler. - Resethandler eingefügt, der einen Reset so lange verzögert, bis alle laufenden Ein-/Ausgabeoperationen auf die Festplatte abgeschlossen sind. Ein Validieren der Festplatte nach dem Neustart wird so verhindert. - Fehler behoben, der verursachte, daß VMM beim Schreiben der ersten Seite auf eine Festplatte mit DMA hing. - Kleinere Änderungen und Aufräumarbeiten. @EndNode @Node "To_2_0" "VMM/doc/VMM.guide/To_2_0" @Prev "To_1_3" @Next "To_2_1" @Toc "Main" Änderungen von V1.3 zu V2.0: - VMM läuft jetzt auf dem 68030. Daher wurde es von VMM40 zu VMM umbenannt. - Sogenannte Pseudo-Partition implementiert. Diese sieht aus wie eine Datei, darauf kann jedoch mit der Geschwindigkeit einer Partition zugegriffen werden. - VMM ist jetzt ein Commodity, dessen Benutzerschnittstelle mittels eines Hotkeys angezeigt wird. Daher hat sich der Aufbau von VMM etwas verändert. VMM40 wurde nach L:VMM-Handler umbenannt und VMM40Prefs heißt jetzt nur noch VMM. Das VMM: Assign und das StartVMM-Programm sind damit überflüssig. - Hoffentlich alle Probleme mit DMA-Geräten beseitigt (CachePreDMA und CachePostDMA gepatcht). - Das Benutzerinterface wurde erweitert, um einige neue Einstellmöglichkeiten aufzunehmen. - VMM patcht jetzt die Titelzeile der Workbench, um dort den freien virtuellen Speicher mit anzuzeigen. Dies wird durch einen Schalter freigegeben. - Saubereres Verlassen von VMM, falls noch virtueller Speicher allokiert ist. - Weitere kleine Fehlerbehebungen und Erweiterungen. @EndNode @Node "To_2_1" "VMM/doc/VMM.guide/To_2_1" @Prev "To_2_0" @Next "To_3_0" @Toc "Main" Änderungen von V2.0 zu V2.1: - AvailMem liefert jetzt den freien physikalischen Speicher zurück, falls eine Task keinen virtuellen Speicher verwenden darf. - Fehler behoben, der dazu führte, daß VMM abstürzte, wenn die Einstellungsdatei nicht gefunden wurde. Jetzt wird ein Requester geöffnet. - Fehler bei der Installation behoben, der die Standard-Einstellungsdatei nicht kopierte. - Schreibpuffer implementiert, der mehrere Seite auf ein Mal auf die Platte schreibt. Zwar müssen dafür die Seiten einmal umkopiert werden, meist resultiert dies aber in einem substantiellen Geschwindigkeitsgewinn. - Die Option, den größten freien Speicherblock für die Kacheln zu verwenden, wurde gelöscht, da offensichtlich niemand dies benutzt. - Auslagerung auf Datei wurde drastisch beschleunigt, indem zusätzliche Puffer beim Dateisystem angefordert werden. FFS und OFS sind leider sehr ineffizient bei der Positionierung in langen Dateien. VMM fordert so viele Puffer an, wie für die Speicherung der Dateiverkettungsinformation benötigt werden. Andere Dateisysteme wie das MSDOS-Dateisystem benötigen dies nicht. - FreeMem markiert freigegebene Seiten nun als unbenutzt und nicht als ungültig. Vorher wurde beim nächsten Zugriff jeweils ein Seitenfehler ausgelöst, der jedoch keinen Plattenzugriff hervorrief. - Fontberechnung für Statistikfenster korrigiert. - Verbesserte Fehlerbehandlung - Schwer zu findenden Fehler behoben, der zufällige Abstürze auf Systemen mit 68030 und 68882 hervorrief. Ich hatte die benötigte Stackgröße bei einem Seitenfehler unterschätzt, wenn die FPU beschäftigt ist. - Unterstützung für externe Statistikprogramme implementiert. Es können nun eigene (z.B. grafische) Statistiktools für VMM geschrieben werden. - DOS Fehler umgangen, der Fehler bei Pseudo-Partitionen auf Partitionen mit dem gleichen Volume- und Devicenamen verursachte. @EndNode @Node "To_3_0" "VMM/doc/VMM.guide/To_3_0" @Prev "To_2_1" @Next "To_3_1" @Toc "Main" Änderungen von V2.1 zu V3.0: - Code-Paging eingebaut, d.h. man kann jetzt den Programmcode in den virtuellen Speicher legen und VMM lagert diesen aus wie normalen Speicher. - Speicher-Tracking eingebaut. Es ist nun möglich zu verfolgen, welche Task wieviel virtuellen Speicher verwendet. - Zusätzlicher Modus zur Angabe des Hauptspeichers für den virtuellen Speicher. Der 'eingeschränkt dynamische Modus' funktioniert wie der dynamische Modus mit einer Angabe für Unter- und Obergrenze des belegten Speichers. - Komplett neue Benutzeroberfläche, die MUI verwendet. Dadurch werden jetzt auch verschiedene Sprachen unterstützt. - Hoffentlich Probleme mit einigen Prozessorkarten beseitigt, indem die Transparent Translation Register besser genutzt werden. - Zusätzliches 'spezielles MMU-Setup' implementiert, das alle Karten, die bisher Probleme bereiteten, zur Zusammenarbeit bringen sollte. - VMM kann über ARexx angesteuert werden. - VMM unterstützt nun die Kombination 68020 + 68851. - Fehler behoben, der VMM eine Nachricht ' Nicht genug Speicher' ausgeben ließ, wenn das Statistikfenster während des Programmlaufs geöffnet wurde. - Das Format der Konfigurationsdatei wurde auf ein Binärformat geändert. Es gibt ein Programm zum Konvertieren der alten Konfigurationsdateien. @EndNode @Node "To_3_1" "VMM/doc/VMM.guide/To_3_1" @Prev "To_3_0" @Next "To_3_2" @Toc "Main" Änderungen von V3.0 zu V3.1: - Fehler behoben , der verhinderte, daß VMM unter OS2.0 lief. Ein mir unbekanntes Auto-OpenLibrary der libnix-Library versuchte die Locale.library zu öffnen. Wenn diese nicht vorhanden war, weigerte sich VMM zu starten. - Es gibt nun ein neues Schlüsselwort 'FORCE'. Wenn es im Icon oder auf der Kommandozeile angegeben wird, fragt VMM nicht mehr nach, ob eine vorher anderweitig genutzte Partition überschrieben werden soll. Dies ist insbesondere für Leute nützlich, die die Swap-Partition z.B. für LINUX nutzen möchten. - Die Obergrenze des verfügbaren virtuellen Speichers wurde nach mehreren Anfragen von 128 MB auf 512 MB erhöht. - Es gibt nun eine FastROM option für VMM. Auf manchen Rechnern gibt es Probleme mit anderen Tools, die eine FastROM-Option anbieten. - Pseudo-Partitionen sind jetzt auch auf DC-FFS Partitionen möglich. - Es wurde ein Algorithmus zum Sammeln unbenutzter Seiten implemen- tiert. Dies reduziert die Anzahl der Plattenzugriffe wegen Seiten- fehlern um bis zu 30 %. - Fehler im Resethandler behoben, der auf manchen Rechner beim Reset einen GURU hervorrief. - Kleinen Fehler behoben, der VMM manchmal veranlaßte, immer wieder Speicher freigeben zu wollen . Diese passierte meistens, wenn das Chip-Memory knapp wurde. - Das MMU-Mapping wurde leicht verändert, wenn die VMM_MMU.config- Datei verwendet wird. Vorher konnte VMM auf manchen Rechnern nicht starten, da es versuchte für die kompletten 4 GB Adressraum Seiten- tabellen anzulegen (4 MB). - Das Memory-Tracking wurde geändert, so daß das jeweilige Programm als Besitzer seines Codes angezeigt wird und nicht die Task, die den entsprechenden Speicher allokiert. Dies ist hauptsächlich für Libraries von Interesse. - Fehler gefunden, den ich schon lange gesucht habe. Ein Fehler in ramlib führte zu nicht reproduzierbaren Abstürzen. Ein Patch wird wenn möglich von VMM durchgeführt. - Kleinen Fehler behoben, wegen dem VMM fälschlicherweise Partitionen mit ein anderen Blockgröße als 512 Byte für Pseudo-Partitionen akzeptierte. - Workaround für einen Fehler in GCC eingebaut, der VMM immer die Standardeinstellungen für die Compilerpässe benutzen ließ. @EndNode @Node "To_3_2" "VMM/doc/VMM.guide/To_3_2" @Prev "To_3_1" @Next "TO_3_3" @Toc "Main" Änderungen von V3.1 zu V3.2: - Enforcer-Hit entfernt, der auftrat, wenn VMM mit dem Statistik- fenster als Titelzeile gestartet wurde. - Mögliche Resetverzögerung entfernt. - Fehler in ReadMMUConfig behoben. Wenn es mit 8K-Seiten verwendet wurde, wurde eine leere VMM_MMU.config-Datei erzeugt. - Man kann jetzt auch Verzeichnisse in der Task-Liste eingeben. Man kann so seine Programme in Verzeichnisse gruppieren, für die die gleichen Einstellungen gelten sollen. Nur Dateien direkt aus dem angegebenen Verzeichnis werden berücksichtigt, nicht die Dateien aus Unterverzeichnissen. - VMM erkennt jetzt automatisch LINUX-Swap-Partitionen. @EndNode @Node "To_3_3" "VMM/doc/VMM.guide/To_3_3" @Prev "To_3_2" @Next "To_3_3a" @Toc "Main" Änderungen von V3.2 zu V3.3: - Die Ausgabe von VMMUsageCLI sieht jetzt etwas schöner aus (empfohlen von Steve Koren). - Jeder Eintrag in der Taskliste kann jetzt beliebig lang sein. Dies ist insbesondere für komplizierte Suchmuster wichtig. - VMM läuft jetzt auch auf dem 68060. - Fehler behoben, der eine Absturz hervorrief, wenn die FastROM-Option auf einem 68030 eingeschaltet wurde. @EndNode @Node "To_3_3a" "VMM/doc/VMM.guide/To_3_3a" @Prev "To_3_3" @Next "VMMPREFS" @Toc "Main" Änderungen von V3.3 zu V3.3a - Deutsche Dokumentation - Russische Sprachunterstützung - Update der BGUI-Oberfläche @EndNode @Node "VMMPREFS" "VMM/doc/VMM.guide/VMMPREFS" @Next "Tasks_Gadget" @Prev "To_3_3" @Toc "Main" 5. DAS EINSTELLUNGS-FENSTER Um alle nötigen Einstellungen einzugeben, die VMM zum Arbeiten benötigt, existiert eine graphische Benutzeroberfläche, die MUI verwendet. Fast alle Parameter können geändert werden, während VMM läuft. Wo dies nicht möglich ist, ist es entweder unsinnig oder sehr schwierig zu implementieren. Es gibt drei Hauptbereiche in den Einstellungen von VMM: @{" Tasks / Programme " Link "Tasks_Gadget"} @{" Speichereinstellungen" Link "Memory_Settings"} @{" Verschiedenes " Link "Misc_Settings"} Die drei Knöpfe an der unteren Kante des Fensters funktionieren wie bei jedem Einstellungsprogramm. Die Auswahl von 'Abbrechen' läßt VMM die Änderungen der Einstellungen vergessen und startet anschließend. Wenn Sie VMM verlassen wollen, wählen Sie 'Beenden' im Menü oder starten Sie VMM ein zweites Mal mit dem Parameter 'QUIT'. @EndNode @Node "Tasks_Gadget" "VMM/doc/VMM.guide/Tasks_Gadget" @Next "Memory_Settings" @Prev "VMMPREFS" @Toc "Main" Liste der Tasks / Programme: VMM führt eine Liste von Tasks/Programmen, die spezielle Aufmerksamkeit erfordern, wenn sie virtuellen Speicher nutzen sollen. Zusätzlich gibt es eine Standardeinstellung. Virtueller Speicher kann entweder standardmäßig ausgeschaltet werden, um dann die Programme in die Liste einzutragen, die virtuellen Speicher nutzen sollen oder genau entgegengesetzt. Der Name, der in die Liste eingetragen wird, kann ein Taskname, ein Programmname (ohne Pfad), ein Verzeichnis oder ein AmigaDOS-Muster sein, das die Programme spezifiziert, die mit oder ohne virtuellen Speicher laufen sollen. Bei Verwendung eines Verzeichniseintrags sind alle Programme aus diesem Verzeichnis betroffen, nicht jedoch die Programme in dessen Unterverzeichnissen. Dies trifft leider nur auf DOS-Prozesse zu, da es keinen Weg gibt festzustellen, welches Programm eine einfache Exec-Task ausführt. Für jeden Eintrag werden zwei Fälle betrachtet: 1. Code Paging: Dies bestimmt, ob der Programmcode für das angegebene Programm in den virtuellen Speicher geladen wird. 2. Daten Paging: Hier existieren drei Möglichkeiten: Virtueller Speicher wird verwendet, wenn bei der Speicheranfrage das PUBLIC- Bit nicht gesetzt ist, er wird nie verwendet oder es werden Zusatz- optionen ausgewertet. Die Zusatzoptionen wurden implementiert, da es Programme gibt, die entweder immer ihren Speicher mit dem Public-Flag allokieren oder die das Public-Flag dort weglassen, wo es benötigt wird. Um diese Programme mit VMM lauffähig zu machen, kann man VMM mitteilen, wie groß ein Block mindestens sein soll, damit er in den virtuellen Speicher kommt. Wenn man eine Zahl in eines der beiden Felder einträgt, werden alle Allokationen, die größer sind als diese Zahl, in den virtuellen Speicher gelegt. Diese Einstellung kann für Allokationen mit und ohne Public-Flag getätigt werden. Der spezielle Wert -1 teilt VMM mit, daß keine Allokation mit diesem Flag in den virtuellen Speicher gehen soll. Da dies etwas schwierig zu erklären ist, folgen zwei Beispiele. Beispiel 1: Ein Programm allokiert all seinen Speicher mit dem Public- Flag und benutzt daher keinen virtuellen Speicher. Abhilfe: Setzen Sie das Feld "Min. PUBLIC Allok." auf einen Wert, z.B. 200. Den sinnvollsten Wert müssen Sie herausfinden. Nun werden alle kleinen Allokationen, deren Public-Flag gesetzt ist, in normalen Speicher umgeleitet, während die größeren virtuellen Speicher verwenden. Tragen Sie 0 in das Feld "Min. non-PUBLIC Allok." ein, um VMM mitzuteilen, daß alle Allokationen ohne das Public-Flag in den virtuellen Speicher sollen. Beispiel 2: Ein Programm allokiert Systemstrukturen ohne das Public-Flag und stürzt daher ab. Abhilfe: Setzen Sie das Feld "Min. non-PUBLIC Allok." z.B. auf 200 und das "Min. Public Allok."-Feld auf -1. Auf diese Weise werden Systemstrukturen, die meist kleiner sind als 200 Bytes, in den öffentlichen Speicher gelegt. Der Zustand "VM benutzen" entspricht einer Einstellung von -1/0 für die "Min Public / min non-Public"-Felder. Der Zustand "VM nicht benutzen" entspricht -1/-1. Falls ein zu überprüfender Name auf zwei Einträge in der Liste paßt, wird der erste der beiden verwendet. Falls er zu keinem Eintrag paßt, werden die Standardeinstellungen verwendet. Auf diese Weise kann z.B. die muimaster.library virtuellen Speicher verwenden, während ein weiter hinten stehendes "#?.library" allen anderen Libraries den virtuellen Speicher verwehrt. Falls Sie Probleme haben, die nötigen Einstellungen herauszufinden, können Sie das @{"Memory Tracking" Link "Misc_Settings"} verwenden, um für jeden Prozeß herauszufinden, wieviel virtuellen Speicher er verwendet. @EndNode @Node "Memory_Settings" "VMM/doc/VMM.guide/Memory_Settings" @Prev "Tasks_Gadget" @Next "MemType_Gadget" @Toc "Main" Dieser Abschnitt bestimmt die Einstellungen für das Auslagerunggerät und der Menge Speicher, die für das Auslagern verwendet wird. @{" Auslagerungsspeicher " Link "MemType_Gadget"} @{" Speicherart " Link "MemFlags_Gadget"} @{" Schreibpuffer " Link "WriteBuffer_Gadget"} @{" VM Priorität " Link "MemPri_Gadget"} @{" Auslagerungsmedium " Link "SwapMedium_Gadget"} @{" Dateigröße " Link "FileSize_Gadget"} @EndNode @Node "MemType_Gadget" "VMM/doc/VMM.guide/MemType_Gadget" @Next "MemFlags_Gadget" @Prev "Memory_Settings" @Toc "Main" Speicherallokation für die Kacheln: Es gibt drei verschiedene Strategien zur Speicherallokation: - Feste Größe: VMM allokiert beim Start soviel Speicher wie im Feld darunter angegeben. - Dynamisch: VMM allokiert Speicher und gibt ihn wieder frei, wie er zur Laufzeit benötigt wird. - Eingeschränkt dynamisch: Diese Option funktioniert wie die dynamische Einstellung, außer daß der verwendete Speicher durch die eingestellten Minimal- und Maximal- werte begrenzt wird. @EndNode @Node "MemFlags_Gadget" "VMM/doc/VMM.guide/MemFlags_Gadget" @Next "WriteBuffer_Gadget" @Prev "MemType_Gadget" @Toc "Main" Speicherart für Kacheln: Dieses Feld spezifiziert die Art des Speichers, die VMM zum Auslagern verwendet. Entweder Fast, Chip oder Any können gewählt werden. Normalerweise ist beim Chip-Memory das Caching des Prozessors abgeschaltet, daher können dann auch Kacheln in diesem Bereich nicht gecacht werden. Möglicherweise wird aber bei einigen 68040-Karten das Caching für das Chip-Memory nicht abgeschaltet, sodaß dieses für das Auslagern durchaus verwendet werden kann. @EndNode @Node "WriteBuffer_Gadget" "VMM/doc/VMM.guide/WriteBuffer_Gadget" @Next "MemPri_Gadget" @Prev "MemFlags_Gadget" @Toc "Main" Schreibpuffer: Ab V2.1 verwendet VMM einen Schreibpuffer, um mehrere Seiten auf einmal schreiben zu können. Dies beschleunigt den Zugriff sehr stark, da Positionierungen des Kopfes und sonstiger Overhead vermieden werden. Mit diesem Feld können Sie die Größe des verwendeten Schreibpuffers einstellen. Ein Schreibpuffer von 100 bis 200 K genügt in den meisten Fällen. @EndNode @Node "MemPri_Gadget" "VMM/doc/VMM.guide/MemPri_Gadget" @Prev "WriteBuffer_Gadget" @Next "SwapMedium_Gadget" @Toc "Main" VM Priorität: Hier können Sie einstellen, wann virtueller Speicher allokiert wird. Exec durchsucht alle Speicherlisten in einer bestimmten Reihenfolge, in der normalerweise der Fast-Speicher als erstes mit der Priorität 30 steht. Der Chip-Speicher hat die Priorität -10. Wenn Sie also wollen, daß der virtuelle Speicher zuerst verwendet wird, müssen Sie eine Zahl größer 30 einstellen. Wenn Sie normalen Fast-Speicher zuerst verwenden wollen, aber virtuellen, bevor der Chip-Speicher benutzt wird, verwenden Sie eine Zahl zwischen -10 und 30. Wenn Sie die dynamische Speicherallokation für Kacheln eingestellt haben, sollte der virtuelle Speicher die höchste Priorität im System erhalten. Sonst ist fast der gesamte physikalische Speicher belegt, und VMM muß den virtuellen Speicher in einem sehr kleinen physikalischen Speicherfenster abbilden. @EndNode @Node "SwapMedium_Gadget" "VMM/doc/VMM.guide/SwapMedium_Gadget" @Next "FileSize_Gadget" @Prev "MemPri_Gadget" @Toc "Main" Auslagerungsmedium: Es gibt drei Möglichkeiten für das Auslagerungsmedium: - Auslagern auf eine Partition: Beim Anwählen dieser Option müssen Sie die Partition eingeben, die Sie zum Auslagern verwenden wollen. Wenn eine Partition zum ersten Mal von VMM zum Auslagern verwendet wird, erfolgt eine Sicherheitsabfrage, um ein versehentliches Überschreiben der falschen Partition zu verhindern. - Auslagern auf eine Datei: Hier müssen Sie eine Dateinamen angeben, der zum Auslagern verwendet wird. Normalerweise ist diese Art deutlich langsamer als das Auslagern auf eine Partition. - Auslagern auf eine sogenannte Pseudo-Partition: Pseudo-Partitionen sind Dateien, die auf der Festplatte am Stück angelegt werden. Dadurch kann auf Sie genauso schnell wie auf eine normale Partition zugegriffen werden, weiterhin kann sie wie eine normale Datei angesehen und gelöscht werden. VMM erzeugt diese Art von Datei selbständig in der gewünschten Größe. Falls eine Datei bereits existiert, führt VMM beim Start eine Konsistenzprüfung durch. Pseudo-Partitionen sind zur Zeit nur mit FFS-Dateisystem mit einer Blockgröße von 512 Bytes möglich. Da Pseudo-Partitionen ihren Platz am Stück benötigen und FFS den Root-Block in der Mitte der Partition anlegt, kann sie höchstens halb so groß wie die Partition sein, auf der sie sich befindet. Eine kleine Warnung an dieser Stelle: Dies kann ein gefährliche Option sein. Falls sich in diesem Teil von VMM ein Fehler befindet, kann es passieren, daß unschuldige Daten überschrieben werden. Dieser Teil von VMM ist aber inzwischen gut getestet worden und sollte eigentlich keine Probleme bereiten. Diese Einstellung und die Größe der Auslagerungsdatei können nicht während des Laufs von VMM verändert werden. @EndNode @Node "FileSize_Gadget" "VMM/doc/VMM.guide/FileSize_Gadget" @Prev "SwapMedium_Gadget" @Next "Misc_Settings" @Toc "Main" Größe der Auslagerungdatei: Dieser Slider bestimmt die Größe der Auslagerungsdatei bzw. der Pseudo-Partition. Diese Einstellung und das Auslagerungsmedium können nicht während des Laufs von VMM verändert werden. @EndNode @Node "Misc_Settings" "VMM/doc/VMM.guide/Misc_Settings" @Prev "FileSize_Gadget" @Next "PROC_DIFFS" @Toc "Main" Statistik: VMM kann ein Statistikfenster öffnen, das Sie über den Zustand des virtuellen Speichers informiert. Unter anderem finden Sie hier die Anzahl der Seitenfehler, die Anzahl der Plattenzugriffen, den freien virtuellen Speicher usw. Dieses Fenster kann ein- und ausgeschaltet werden oder in eine flache Titelzeile verwandelt werden. Zorro II RAM cachen: Auf einigen Amigas mit 68040-Karte muß das Caching des RAMs im Zorro II-Bereich abgeschaltet werden. Diese Einstellung wird ignoriert, wenn Sie die VMM_MMU.config Datei verwenden. VM in WB-Titel anzeigen: Nach vielen Bitten, die Workbench-Titelzeile zu patchen, um den virtuellen Speicher dort anzuzeigen, habe ich dies implementiert. Da es sich hier jedoch um einen üblen Hack handelt, kann es sein, daß dies unter bestimmten Umständen nicht funktioniert. Speicher protokollieren: Wenn diese Option eingeschaltet ist, protokolliert VMM jede Allokation von virtuellem Speicher mit. Dabei wird die Größe der Allokation und der Name der entsprechenden Task gespeichert. Mit dem VMMUsage-Programm ist es möglich, sich eine Liste aller Programme ausgeben zu lassen, die virtuellen Speicher verwenden. Diese Option ist hauptsächlich dafür gedacht, um herauszufinden, unter welchem Namen VMM die Tasks führt. Manchmal ist dies nicht der Name, den man erwartet, und daher eignet sich dies sehr gut, um kooperationsunwillige Programme zur Zusammenarbeit zu bewegen. Wenn Sie diese Einstellung während des Laufs ausschalten, wird der Speicher, der zum Protokollieren verwendet wird, nicht wieder freigegeben. Fast ROM: Das Einschalten dieser Option veranlaßt VMM, das ROM ins Fast-RAM zu kopieren und MMU-Tabellen so anzupassen, daß diese Kopie statt des ROMs verwendet wird. Dies beschleunigt den Zugriff auf Systemroutinen oft erheblich. Diese Option wurde implementiert, da einige Tools mit FastROM-Option nicht mit VMM zusammenarbeiten. Diese Option wird ignoriert, wenn Sie eine VMM_MMU.config Datei verwenden. Minimale VM Allokation: Um die AllocMem-Routine zu beschleunigen, die vom gesamten System sehr häufig verwendet wird, wird für Allokationen, die kleiner sind als der hier angegebene Wert normales Fast-RAM verwendet. Wenn Sie den Wert auf 0 setzen, wird jede mögliche Allokation in den virtuellen Speicher gelegt. Ein Wert von 100 bis 200 stellt einen vernünftigen Kompromiß zwischen der Speicherausnutzung und der Geschwindigkeit dar. Hotkeys: Es gibt zwei zusätzliche Hotkeys, die es Ihnen einfach erlauben, die Allokation von virtuellen Speicher zwischendurch zu verbieten bzw. wieder einzuschalten. Die Einträge müssen den normalen Commodities-Spezifikationen genügen. Der Popup-Hotkey kann nur über die Kommandozeile oder die Tooltypes einstellt werden. @EndNode @Node "PROC_DIFFS" "VMM/doc/VMM.guide/PROC_DIFFS" @Next "PROBLEMS" @Prev "Misc_Settings" @Toc "Main" 6. PROZESSORABHÄNGIGE UNTERSCHIEDE: Es gibt einige Unterschiede in VMM bzgl. der Behandlung des virtuellen Speichers wegen der verschiedenen Prozessortypen, die unterstützt werden. Auf der einen Seite sind zwischen 68020+68851 und dem 68030 kaum Unterschiede, während auf der anderen Seite der 68040 und 68060 sehr ähnlich sind. Zuerst einmal installiert VMM auf dem 68030 fast immer seine eigene MMU-Tabelle. Dies liegt daran, daß die Standard-Einstellung entweder überhaupt keine Tabelle oder eine mit einer anderen Seitengröße verwendet. Dies bedeutet, daß auf dem 68030 VMM nicht mit Enforcer zusammenarbeitet. Ab V2.1 enthält VMM einen kleinen undokumentierten Hack, der verhindert, daß bei Softkick-Amigas nach einem Absturz das Kickfile neu geladen werden muß. @EndNode @Node "PROBLEMS" "VMM/doc/VMM.guide/PROBLEMS" @Next "TROUBLESHOOTING" @Prev "PROC_DIFFS" @Toc "Main" 7. SCHWIERIGKEITEN Commodore definierte das MEMF_PUBLIC-Flag für die AllocMem-Funktion vor einer langen Zeit, als niemand sich vorstellen konnte, wozu dies gut sein könnte. Daher verwenden viele Programme dieses Flag entweder immer oder gar nicht. Im ersten Fall passiert nichts Schlimmes, nur verwendet dieses Programm nie virtuellen Speicher. Im zweiten Fall kann es aber passieren, daß das entsprechende Programm abstürzt. Es gibt eine Menge Programme, die IORequests o.ä. auf dem Stack allokieren. Falls dieser im virtuellen Speicher liegt, kann das einen Absturz hervorrufen. Solchen Programmen kann man verbieten, virtuellen Speicher zu verwenden. Wenn Sie selbst Programme schreiben, die auch mit VMM zusammen noch funktionieren sollten, sollten Sie die Datei "VMProgGuideline" lesen, um bestimmte Dinge in Programmen mit virtuellem Speicher vermeiden zu können. Festplattencaches wie FastCache oder PowerCache sollten keinen virtuellen Speicher erhalten, da dies wohl wenig Sinn macht. Das gleiche gilt für alle Programme, die den BeginIO-Vektor des Auslagerungsgeräts verändern. Wenn Sie Software-Festplattencaches verwenden, muß möglicherweise auch den Dateisystem-Tasks (DH0, DH1,..) die Verwendung von virtuellem Speicher untersagt werden. Programme, die den Seitenfehlervektor verändern (z.B. Enforcer), müssen vor VMM gestartet werden, da Enforcer sonst alle Seitenfehler als ungültige Speicherzugriffe anzeigt. Das Code-Paging sollte nicht für Programme verwendet werden, die Input- oder Interrupt-Handler beinhalten. Als Beispiel mag hier die 'ixemul.library' dienen. @EndNode @Node "TROUBLESHOOTING" "VMM/doc/VMM.guide/TROUBLESHOOTING" @Next "TECHNICAL_DES" @Prev "PROBLEMS" @Toc "Main" 8. HÄUFIG AUFTRETENDE PROBLEME Frage : Programm "X" verwendet keinen virtuellen Speicher. Warum? Antwort: Möglicherweise setzt das Programm bei jedere Allokation das MEMF_PUBLIC-Flag. Um dies zu umgehen, verwenden Sie die Zusatzoptionen. Frage: VMM stürzt mit meiner Konfiguration ab. Antwort: Es gibt zwei Möglichkeiten, warum dies passiert. Wenn VMM sofort beim Start oder beim ersten Festplattenzugriff abstürzt, handelt es sich meist um ein Problem mit der MMU- Tabelle. In diesem Falle lesen Sie @{"MMU setup" Link "MMU_SETUP"}. Die andere Möglichkeit ist, daß sich in Ihrer Umgebung ein Programm befindet, daß keinen virtuellen Speicher verträgt. Wenn dies der Fall ist, tun Sie Folgendes: Setzen Sie Standardeinstellung auf "VM nicht benutzen" und stellen Sie die Einstellung für den für VMM verfügbaren physikalischen Speicher auf das Minimum, damit VMM gezwungen ist, häufig Seiten auszulagern . Dann erlauben Sie nach- einander jeder Task in Ihrem System, virtuellen Speicher zu verwenden. Auf diese Weise könne Sie feststellen, welches Programm keinen virtuellen Speicher verträgt. Anschließend können Sie für dieses Programm den virtuellen Speicher ver- bieten. Zusätzlich können Sie auch die Option @{"Speicher protokollieren" Link "Misc_Settings"} verwenden. Frage: VMM hält das System an, wenn auf eine Partition zugegriffen wird, die sich auf der gleichen physikalischen Platte befindet wie die Auslagerungpartition. Warum? Antwort: Wahrscheinlich verwendet Ihr Festplattentreiber DMA-Zugriffe, ohne bestimmte Systemroutinen korrekt aufzurufen. Als Abhilfe können Sie mit HDToolbox den Maskenparameter für alle Partitionen auf dieser Platten umsetzen. Wenn Sie nicht wissen, was der Maskenparameter ist, setzen Sie ihn auf 0xfffffe, auf diese Weise werden DMA-Zugriffe auf die unteren 16 MB beschränkt. Dieser Fehler sollte ab V2.0 nicht mehr auftreten, wenn doch, so schicken Sie mir eine Mail. Frage: Mein Festplattencache funktioniert nicht, obwohl er keinen virtuellen Speicher erhält. Warum? Antwort: Einige Programme verändern Code, der von anderen Tasks aus- geführt wird. Z.B. verändert DynamiCache den BeginIO-Vektor der gecachten Geräte, sodaß alle Allokationen für die Caches nicht von DynamiCache selbst, sondern von den Dateisystem- Tasks durchgeführt werden. Wenn dies ein Problem ist, müssen Sie für alle Tasks, die den veränderten Code ausführen, den virtuellen Speicher ausschalten. Wegen eines Problems im Zusammenhang mit dem Copyback-Cache von Powercache siehe auch @{"Bekannte Fehler" Link "KNOWN_BUGS"}. Frage: Das System stürzt ab, wenn man in der VMM-Oberfläche "Speichern", "Benutzen" oder "Abbrechen" anklickt. Antwort: Es kann sein, daß Ihre MMU nicht korrekt funktioniert. Leider gibt es keinen Möglichkeit, dies durch Software zuverlässig herauszufinden. Sie müssen das Gerät öffnen und sich die Bezeichnung Ihres Prozessors ansehen. Falls sich in dieser die Buchstaben "EC" befinden, enthält er keine voll funktionsfähige MMU und VMM läuft nicht. Motorola verkauft die Prozessoren, deren MMUs den Endtest nach der Produktion nicht bestanden haben als EC-Typen. Es kann sich dabei um einen nur kleinen Defekt handeln, sodaß die MMU für die meisten Programm voll funktionsfähig erscheint. Falls die MMU nicht defekt ist, kann es sich um ein Problem mit der MMU-Tabelle handeln (s. @{"MMU-Tabelle" Link "MMU_SETUP"}). Frage: Was sind die Vor- und Nachteile von 4K und 8K-Seiten? Antwort: Normalerweise sollten Sie der Empfehlung des Installations- programmes bzgl. der Seitengröße folgen. Es kann aber durch- aus sein, daß VMM bei Ihnen auch mit einer anderen Seiten- größe funktioniert. Bei 4K-Seiten ist die Rate der Seiten- fehler bei Standardapplikationen normalerweise geringer als mit 8K-Seiten. Wenn Sie häufig Bildbearbeitung mit AdPro oder ähnlichen Programmen betreiben, können 8K-Seiten deutlich schneller sein. Dies gilt generell, wenn Sie mit Programmen arbeiten, die auf den Speicher in einer linearen Weise zugreifen. @EndNode @Node "TECHNICAL_DES" "VMM/doc/VMM.guide/TECHNICAL_DES" @Next "MMU_SETUP" @Prev "TROUBLESHOOTING" @Toc "Main" 9. TECHNISCHE BESCHREIBUNG VMM besteht aus drei Tasks, beim Einschalten des Statistikfensters wird eine vierte erzeugt. Die erste ist der VM_Manager, der entscheidet, welcher Prozeß virtuellen Speicher erhält, usw. Der PageHandler führt das Aus- und Einlagern von Seiten durch, wenn ein Seitenfehler aufgetreten ist. Der Prepager verankert Seiten im physikalischen Speicher, wenn IO von oder zur gleichen Platte ausgeführt wird, auf der die Auslagerungspartition liegt. Der meiste Aufwand wurde nicht dafür betrieben, das Auslagern lauffähig zu machen, sondern für die korrekte Behandlung von virtuellem Speicher in allen Situationen. Leider hat Commodore sich seinerzeit recht wenig Gedanken zum Thema virtueller Speicher gemacht, sodaß einige Systemfunktionen verändert werden mußten. Ich habe versucht, VMM so systemkonform wie möglich zu halten, aber leider mußte ich einige Annahmen über undokumentiertes Verhalten machen. Die übelste davon ist die Tatsache, daß ich die Switch-Funktion patchen mußte, die eine Task vom laufenden Zustand in Bereit-Zustand versetzt. Dies bedeutet, daß VMM evtl. mit zukünftigen Versionen des Betriebssystems nicht arbeitet, obwohl wohl in diesem Basiscode nichts mehr geändert werden wird. Außerdem hat Commodore nie etwas darüber veröffentlicht, ob man auf nicht als Public gekennzeichneten Speicher innerhalb eines Forbid/Permit bzw. Disable/Enable zugreifen darf. Wenn in diesem Bereich ein Seitenfehler auftritt, kann es zu gefährlichen Nebenwirkungen kommen, da durch einen Seitenfehler ein Taskwechsel erfolgt. Speicher, der innerhalb eines solchen Bereiches freigegeben wird, wird erst nach dem Verlassen dieses Abschnitts wirklich freigegeben. Momentan ist die Anzahl der gleichzeitig in Bearbeitung befindlichen Seitenfehler plus der Anzahl der Tasks, deren Stack im virtuellen Speicher liegt, auf 20 begrenzt. Der VM_Manager Prozeß Der VM_Manager startet alle anderen Tasks und initialisiert alles. Er behandelt auch das Beenden von VMM. Jedes Mal, wenn AllocMem aufgerufen wird, muß VMM entscheiden, ob der aufrufende Prozeß berechtigt ist, virtuellen Speicher zu verwenden. Wenn ein Prozeß zum ersten Mal AllocMem aufruft, wird eine Nachricht an den VM_Manager geschickt, der entscheidet, ob diese Task virtuellen Speicher erhält. Weitere Allokationen dieser Task werden über eine Hashtabelle entschieden, um die Allokation schnell zu halten. Außerdem behandelt der VM_Manager alle Nachrichten, die durch das Drücken eines Hotkeys oder durch das Exchange-Programm erzeugt werden. Die PageHandler-Task Alle Aus- und Einlagerungen werden asynchron vom PageHandler bearbeitet. Wenn ein Seitenfehler auftritt, werden all dessen Parameter in eine sogenannte Trapstruktur aufgenommen. Diese Struktur wird von dem im Ausnahmezustand arbeitenden Traphandler an den Pagehandler geschickt. Der PageHandler sucht eine zu ersetzende Seite aus und schreibt diese auf die Platte, falls diese verändert wurde. Zur Auswahl der Seite wird der sogenannte Second Chance-Algorithmus verwendet. Nachdem eine Seite verdrängt wurde, wird die angeforderte Seite eingelesen. Anschließend wird die Task, die den Seitenfehler verursacht hat, benachrichtigt, und kann weiterarbeiten. Während der Plattenzugriffe können andere Tasks laufen und währenddessen auch weitere Seitenfehler verursachen, die sofort behandelt werden. VMM verwendet einen Schreibpuffer für die Seiten, die auf die Platte geschrieben werden müssen. Hier werden die Seiten gesammelt, bis der Puffer voll ist, um diese dann in einem Rutsch zu schreiben. Dies senkt die zum Auslagern benötigte Zeit deutlich. Die Prepager-Task Während ich VMM schrieb, habe ich einige Fälle entdeckt, in denen auf eine andere Partition der gleichen Platte zugegriffen wird, auf der sich die Auslagerungpartition befindet. Da der Gerätetreiber für das Auslagerungsgerät nie wegen eines Seitenfehlers blockieren darf, muß dies vermieden werden. Sämtliche Ein- und Ausgaben an dieses Gerät werden daraufhin untersucht, ob sie virtuellen Speicher verwenden. In diesem Falle wird der Block vorher umkopiert und die Ein-/Ausgabe mit diesem Puffer ausgeführt. Die Statistik-Task Die Statistik-Task wird nur erzeugt, wenn das Statistikfenster eingeschaltet ist. Jede Sekunde werden einige Zeilen über den freien virtuellen Speicher usw. ausgegeben. Gepatchte Systemfunktionen Die folgenden System-Funktionen werden von VMM gepatcht: Switch, AddTask, Wait, AllocMem, FreeMem, AvailMem, CachePreDMA, CachePostDMA, LoadSeg und NewLoadSeg. Auf 68030-Systemen wird zusätzlich ColdReboot gepatcht, um den ursprünglichen Zustand der MMU vor dem Reset wieder herzustellen. Außerdem wird noch der BeginIO-Vektor des Auslagerungsgeräts gepatcht. Die Switch-, Wait- und AddTask-Funktionen mußten gepatcht werden, da sich der Stack einer Task möglicherweise im virtuellen Speicher befindet. Um Seitenfehler im Ausnahmezustand (Taskumschaltung) zu verhindern, wird der Stack kurzzeitig durch einen Bereich ersetzt, der groß genug ist, alle Register während einer Kontextumschaltung aufzunehmen. Wenn die Task weiterarbeitet, wird der Originalstack restauriert. Wenn das Anzeigen des virtuellen Speichers in der Titelzeile des Workbench-Screens eingeschaltet ist, wird zusätzlich die SetWindowTitles-Funktion gepatcht. @{"MMU-Tabelle" Link "MMU_SETUP"} @EndNode @Node "MMU_SETUP" "VMM/doc/VMM.guide/MMU_SETUP" @Next "VMM_LIBRARY" @Prev "TECHNICAL_DES" @Toc "Main" DIE VON VMM VERWENDETE MMU-TABELLE Falls möglich versucht VMM eine bereits existierende MMU-Tabelle anzupassen. In manchen Fällen geht dies aber leider nicht, wenn z.B. eine andere Seitengröße oder bestimmte MMU-Register verwendet werden (Für Experten: Die sogenannten Transparent Translation Register). Einige Prozessorkarten wie das GForce '040 von GVP, das FusionForty Board und einige GVP-Harddisk-Controller verwenden Adreßbereiche, die von Commodore als reserviert definiert wurden. Es gibt leider keinen Weg, so etwas per Software herauszufinden. Damit man mit diesen Karten VMM nutzen kann, habe ich einen speziellen Mechanismus entwickelt, mit dem man VMM seine MMU-Einstellung mitteilen kann. Es gibt ein Programm namens 'ReadMMUConfig', das die aktuelle MMU-Einstellung für den gesamten 4 GB-Adreßbereich auslesen kann. Diese Information wird in eine Datei geschrieben, die von VMM beim Start gelesen wird. Diese Datei enthält für jeden kontinuierlichen Adreßbereich eine Zeile. VMM erzeugt daraufhin eine identische Tabelle mit der richtigen Seitengröße, ohne die Spezial-Register zu verwenden. Ab V3.1 ist diese Tabelle dynamisch, d.h. der Speicher für die Seitentabellen wird erst dann allokiert, wenn ein Zugriff auf eine Seite dieses Bereichs stattfindet. In älteren Version kam es dazu, daß die MMU-Tabellen für die kompletten 4GB, d.h. 4 MB beim Start angefordert wurden. Unter Umständen kann es trotzdem erforderlich sein, diese Datei zu editieren, daher eine kurze Beschreibung der Einträge: Jede Zeile enthält die folgenden vier Einträge: Log. Start-Adresse | Phys. start-Adresse | Blocklänge | Flags Dies bedeutet, daß ein Block ab 'log. Startadresse' auf einen Block der Länge 'Blocklänge' ab Adresse 'phys. Startadresse' abgebildet wird. Die Flags sind wie folgt definiert: Bit 0 muß immer gesetzt sein Bit 1 muß immer gelöscht sein Bit 2 muß gesetzt sein, wenn dieser Bereich schreibgeschützt sein soll. Bit 3 und 4 werden ignoriert Bit 5 und 6 bestimmen den Cache-Modus wie folgt: Bit 6 | Bit 5 | 68040 | 68030 and 68851 ------+-------+----------------------------+-------------------------- 0 | 0 | Cacheable, write-through | Cacheable 0 | 1 | Cacheable, copyback | Cacheable 1 | 0 | Noncacheable, serialized | Noncacheable 1 | 1 | Noncacheable | Noncacheable Wenn Sie VMM nicht zum Laufen bekommen, indem Sie diese Datei ändern, schicken Sie mir eine Mail mit der Ausgabe von 'ReadMMUConfig', der Ausgabe von ShowConfig o.ä. und ich werde versuchen, Sie bei der Erstellung einer passenden MMU-Tabelle zu unterstützen. @EndNode @Node "VMM_LIBRARY" "VMM/doc/VMM.guide/VMM_LIBRARY" @Next "EXT_PROGS" @Prev "MMU_SETUP" @Toc "Main" 10. VMM.LIBRARY Es wurde eine Library für VMM entwickelt, die es erlaubt, Programme speziell für VMM zu entwickeln. Sie enthält die Funktionen AllocVMem, FreeVMem, AvailVMem, AllocVVec and FreeVVec. Wenn die Library geladen wird, wird VMM automatisch gestartet, aber nur Programme, die über die vmm.library Speicher allokieren, bekommen virtuellen Speicher. Wenn Sie sowohl die vmm.library als auch VMM auf dem normalen Wege nutzen wollen, müssen Sie zusätzlich VMM wie gewohnt starten. Momentan wird der PageHandler nicht beendet, wenn die Library aus dem Speicher entfernt wird. Eine (englischsprachige) Dokumentation der Library-Funktionen im Autodoc-Format ist vorhanden. @EndNode @Node "EXT_PROGS" "VMM/doc/VMM.guide/EXT_PROGS" @Next "KNOWN_BUGS" @Prev "VMM_LIBRARY" @Toc "Main" 11. EXTERNE PROGRAMME Ab V2.1 ist es möglich, eigene Programme zu schreiben, die die Statistikinformationen von VMM auswerten bzw. darstellen. Es gibt eine C-Include-Datei, die die Message-Struktur beschreibt, die von VMM verwendet wird, um den Status mitzuteilen. Weitere Informationen finden Sie dort. Wenn Sie ein Programm schreiben, daß diese Schnittstelle verwendet, können Sie es mir schicken, damit ich es bei der nächsten Veröffentlichung VMM beilegen kann. Ab V3.0 ist es zusätzlich möglich, auch die Information über die einzelnen VM-verwendenden Tasks von VMM zu erfragen. Falls Sie VMMUsage also nicht mögen oder eine kombinierte Anzeige für Statistik und Speicherverbrauch einzelner Tasks wünschen, können Sie ein entsprechendes Programm schreiben. Die nötige Information entnehmen Sie bitte der o.g. Include-Datei. @EndNode @Node "KNOWN_BUGS" "VMM/doc/VMM.guide/KNOWN_BUGS" @Next "BUG_REPORTING" @Prev "EXT_PROGS" @Toc "Main" 12. BEKANNTE FEHLER So weit mir bekannt befinden sich keine größeren Fehler mehr in VMM. Es gibt jedoch nach wie vor einen kleineren Fehler, der noch behoben werden muß. Wenn eine Task via RemTask von einer anderen Task terminiert wird, und deren Stack in virtuellem Speicher liegt, wird die zugehörige Trap-Struktur nicht freigegeben. Commodore empfiehlt sowieso, RemTask nicht auf andere Tasks anzuwenden, sodaß dies keine ernstzunehmende Beschränkung darstellt. Um dieses Problem zu umgehen, kann man der Task den virtuellen Speicher verbieten, die den Stack allokiert. Es kann passieren, daß VMM wegen Speichermangel nicht starten kann. In diesem Fall versucht es einen Requester öffnen, der diesen Grund angibt. Falls aber selbst hierfür kein Speicher mehr vorhanden ist, gibt es keine Ausgabe. Dies liegt daran, daß man bei der Verwendung von EasyRequestArgs nicht herausfinden kann, ob der Requester wirklich geöffnet werden konnte. Zukünftig sollte hier ein Alert ausgegeben werden. Es gibt ein merkwürdiges Phänomen im Zusammenhang mit dem console.device. Wenn man ein CLI-Fenster öffnet, bleibt der Cursor darin manchmal grau, obwohl das Fenster aktiv ist. Indem man ein anderes Fenster aktiviert und dann wieder das ursprüngliche wird der Cursor aktiviert. Anscheinend allokiert die CON-Task ihren Stack im virtuellen Speicher und ruft dadurch dieses Problem hervor. Wenn man 'CON' den virtuellen Speicher verbietet, verschwindet dieses Problem. Es gibt einen Fehler im Zusammenhang mit dem Copyback-Modus von Powercache. Es können dadurch Dateiinhalte zerstört werden. Dies ist eher ein Fehler in Powercache als in VMM. In der aktuellen Powercache-Version (37.115) gibt es zwei Möglichkeiten, dies zu umgehen: Entweder müssen Sie die Copyback-Option von Powercache ausschalten oder Sie müssen in HDToolbox die Maske für alle Partitionen, die von Powercache gecacht werden, auf 0x0fffffff setzen. Dies beschränkt alle Speichertransfers von und zur Platte auf die unteren 256 MB und vermeidet damit den virtuellen Speicher. Es gibt einen seltsamen Fehler beim Kopieren großer Dateien über die Workbench. Wenn Sie eine große Datei (mind. 10 MB) nach RAM: kopieren wollen, indem Sie die Workbench dazu verwenden, kann dies aus Speichermangel fehlschlagen, obwohl genügend Speicher vorhanden ist. Wenn man das gleiche über das CLI versucht, funktioniert alles. Das liegt daran, daß die Workbench einen Riesenpuffer zum Kopieren verwendet und anschließend für das Ziel nicht genügend Platz frei hat. Dieser Fehler tritt auch ohne VMM mit genügend Speicher auf. VMM patcht den LoadSeg-Vektor um Code-Paging zu ermöglichen. Leider kann dieser Patch nicht einfach die ursprüngliche LoadSeg-Funktion aufrufen, nachdem seine Arbeit getan ist. Daher werden vorherige Patches dieser Funktion ignoriert, nachdem VMM gestartet ist. Wenn z.B. Segtracker vor VMM gestartet wird, wird dessen Patch für alle Programme, deren Code in den virtuellen Speicher geladen wird, nicht durchgeführt. Dies liegt daran, daß das Betriebssystem leider oft seine eigenen Funktionen nicht über die öffentlichen Schnittstellen, sondern über interne Sprünge aufruft. @EndNode @Node "BUG_REPORTING" "VMM/doc/VMM.guide/BUG_REPORTING" @Next "ACKNOWLEDGMENTS" @Prev "KNOWN_BUGS" @Toc "Main" 13. FEHLERMELDUNGEN Falls Sie einen Fehler melden wollen oder eine Verbesserung vorschlagen möchten, verwenden Sie bitte das Fehlermeldungsformular aus diesem Archiv. Ich kann häufig Fragen nicht beantworten, da ich nicht weiß, welche Version von VMM jemand verwendet, welche Hardware vorhanden ist etc. Daher ist das Fehlermeldungsformular sehr wichtig für mich. Sie können meine Adresse unter @{"Verschiedenes" Link "MISCELLANEOUS"} finden. @EndNode @Node "ACKNOWLEDGMENTS" "VMM/doc/VMM.guide/ACKNOWLEDGMENTS" @Next "MISCELLANEOUS" @Prev "BUG_REPORTING" @Toc "Main" 14. DANKSAGUNGEN Ich möchte den folgenden Leuten für Ideen, Verbesserungsvorschläge und Testen der Beta-Versionen danken (in alphabethischer Reihenfolge): Michael Berg (Dänische Übersetzung) Jürgen Barthmann Wayne Cole Torsten Ebeling Markus Eiblmeier Sven Fischer Frank Grimm Magnus Holmgren (Schwedische Übersetzung) Oleg Khimich (Russische Übersetzung) Robert Kiehne Jeff Koons Steve Koren Andree Maedl Manfred Matzinger Barry McConnell Marco Musso (Italienische Übersetzung) Paul Ney Stefan Odendahl Hans Otten Volker Rudolph (für die Unterstützung bei der Portierung auf den 68030) Stefan Schmidt Torsten Stolpmann Erno Tuomainen Emmanuel Vacher (Französische Übersetzung) Nikola Vukovljak Alg Inge Wang Christian Wasner Juergen Zimmermann Ich möchte auch all denen danken, die mir Wünsche und Fehlermeldungen geschickt haben. Ohne sie würde VMM nicht so gut funktionieren. @EndNode @Node "MISCELLANEOUS" "VMM/doc/VMM.guide/MISCELLANEOUS" @Prev "ACKNOWLEDGMENTS" @Toc "Main" 15. VERSCHIEDENES Ich würde mich freuen von Ihnen zu hören, ob VMM bei Ihnen läuft und welche Programme Probleme mit VMM bereiten. Wenn Sie einen Fehler melden, benutzen Sie BITTE das Fehlermeldungsformular aus diesem Archiv. Da die meisten Fehler sehr hardwareabhängig sind, benötige ich Ihre Konfigurationsdaten, um herauszufinden, was schiefläuft. email: apel@tecmath.de Adresse: Martin Apel Konrad Adenauer Str. 7 67663 Kaiserslautern Germany Telefon: 0631 / 24257 Bankverbindung: 145 009 494 Sparkasse Bonn BLZ 380 500 00 @EndNode