Ich habe eine Frage zum paging und virtuellem Speicher, in erstmal der "einfachsten" Form. Also entweder habe ich da etwas falsch verstanden oder es ist sehr häufig sehr dumm formuliert. Ich erkläre einfach mal, was ich unter virtuellem Speicher momentan verstehe:

Es gibt physischen Speicher (der tatsächlich vorhandene RAM z.B.) und virtuellen Speicher. Virtueller Speicher dient dazu, tatsächlich mehr Speicher zu allokieren/verwenden, als im PC vorhanden ist.
Dazu tut man folgendes: Man teil den virtuellen Adressraum in sog. pages gleicher Größe (z.B. 4kB) ein. Jedem dieser "pages" wird ein sog. "frame" (diese haben die gleiche Größe wie die pages und dienen auch zur Einteilung des physikalischen Speichers) zugewiesen. Welche page zu welchem frame gehört speichert man in einer Tabelle.
Jeder Prozess führt nun normal seine Befehle aus. Die MMU berechnet aus den virtuellen Adressen mit denen die Prozesse arbeiten die physikalischen Adressen, sodass der Speicher korrekt adressiert werden kann. Das geschieht, in dem der passende Eintrag in der Tabelle gesucht wird. Ist dieser nicht mit dem present/absent-Bit gekennzeichnet, so muss die geforderte Kachel (frame) erst in den Hauptspeicher geladen werden. Wenn sie vorhanden ist, kann sie direkt adressiert werden. Der Vorteil hierbei ist nun auch beliebig den Hintergrundspeicher zum Auslagern nutzen kann.
Das hierbei noch Segmentierung und/oder mehrstufige Seitentabellen zum Einsatz kommen können ist erstmal uninteressant.

So nun 2 Fragen:
1. Erstmal soweit alles korrekt?
2. Überall lese ich, dass die Seitentabelle teil jedes Prozesses ist, d.h. jeder Prozess hat seine eigene Seitentabelle! Aber wieso denn? Es reicht doch vollkommen aus, eine einzige Seitentabelle anzulegen, die eine eindeutige Abbildung der virtuellen Adressen auf die physikalischen liefert oder nicht?
Im Endeffekt rechnet mir die MMU doch alles aus bzw. ich muss nur den Offset für jeden Befehl herausfinden. Und diesen einen Offset kann doch jeder Prozess für sich speichern, wofür brauche ich da eine ganze Tabelle?
Die MMU muss doch nur die Tabelle kenne um den entsprechenden Offset für den gegebene herauszufinden oder nicht?

Gruß
Pille

Die einzige wirklich einigermaßen schlüssige Erklärung die mir gekommen ist, ist die, dass ein Prozess aus mehreren pages bestehen kann und so sich jede einzelne Zuweisung von page <-> frame merken muss. Aber wenn der Prozess davon Kenntnis hat (also die Zuweisungstabellen in seinem Kontext mit enthalten sind), dann kann der Prozess selber auch direkt die Speicheradresse adressieren und die MMU wird fast nutzlos (außer dass diese die Umrechnung schneller kann). Dann wird das Prinzip des virtuellen Speichers aber irgendwie ausgehebelt, weil dann der Prozess selber dem OS sagen kann, falls ein page fault eintritt, dass bestimmte pages<->frames wieder eingelagert werden müssen oder nicht?

Edit: @Jester: Hatte deinen Post erst nach dem Absenden gelesen: Wie meinst du das genau?
Erstmal habe ich das Problem / sehe die Relevanz von vielen "kleinen" virtuellen Adressräumen zu einem großen Virtuellem Adressraum nicht. Sinn und Zweck des virtuellen Adressraums ist es doch geschickt pages ein- und auslagern zu können. Wieso muss da jeder Prozess sein eigenen virtuellen Adressen haben?
Anders gefragt:
Beispiel: Prozess A und B adressieren beide die virtuelle Adresse 0xff13. Diese wird von der MMU für Prozess A zu z.B. 0xff13 + 0xff4 umgerechnet und für B zu 0xff13 + 0x11d.
Hierbei recht es doch immer die Offsets für die einzelnen Prozesse, also 0xff4 für A und 0x11d für B zu speichern. Das kann ich doch in einer zentralen Tabelle machen...

Das Problem tritt natürlich nicht auf, wenn man dank Paging die Lücken zu einem zusammenhängenden virtuellen Speicherbereich zusammensetzen kann.

Und ob der beschleunigte Kontextwechsel wirklich etwas bringt ist auch so eine Frage. Man braucht um die ganze zentrale Tabelle im TLB zu halten deutlich mehr Cache, und der ist kostbar. Da man während ein Prozess läuft nur einen Bruchteil der Tabelle braucht ist das eher Verschwendung.

Prozess A hat von 0 bis 1MB und Prozess B von 1MB bis 2MB. Die page-Größe ist sehr groß, nämlich 1MB. Nun braucht Prozess A noch etwas platz, also verlangt es wieder 1MB. Pysikalisch liegt dieser nun an stelle 2MB bis 3MB, virtuell für Prozess A jedoch von 1MB bis 2MB.

Du kannst entweder eine Tabelle verwenden. Der "Index" in diese Tabelle wäre dann [Process-ID, Virtual-Address]. Oder du kannst mehrere Tabellen verwenden, eine Pro Prozess. Dann reicht als "Index" [Virtual-Address].

Ich schätze dass es bei den meisten Architekturen einfacher sein wird mehrere Tabellen zu verwenden.
Bei einem Context-Switch muss man dabei auch nur ein Register umschreiben, nämlich das, was auf den Page-Table zeigt. Der Page-Table selbst muss natürlich nicht bei jedem Context-Switch kopiert werden, das wäre ja ein schlimmer Overhead. Ein Prozess hat üblicherweise auch keinen direkten Zugriff auf "seinen" Page-Table. Genau so wie ein Prozess üblicherweise auch nicht direkt physische Adressen verwenden kann.

Die Variante mit nur einer Tabelle würde auch erfordern, dass die im System vorhandene MMU so eine Tabelle überhaupt verwenden kann. Also dass das System auf Hardwareebene bereits etwas ähnlich einer Prozess-ID kennt, und es als Teil des Index für den Page-Table verwenden kann. Ich glaube dass das viele Systeme nicht können.

dann kann der Prozess selber auch direkt die Speicheradresse adressieren und die MMU wird fast nutzlos (außer dass diese die Umrechnung schneller kann).

Also erstmal würde das einen *gewaltigen* Geschwindigkeitsunterschied machen. Und dann könnte man auch keinen Code in so einem "manuell" virtuellen Speicher speichern, zumindest nicht effektiv. Denn den Code holt sich die CPU selbst, ohne dass man bei jedem Zugriff von Hand irgendwelche Datenstrukturen durchackern kann.

BTW: so ein Page-Table - auch einer für nur einen Prozess - ist sowieso keine flache Tabelle. Üblicherweise ist das ein Baum der 2-4 Ebenen "tief" ist. D.h. du hast eine relativ kleine Tabelle, die den Speicher in z.B. Bereiche zu je 64 MB aufteilt. Pro verwendetem 64 MB Stück hast du dann eine weitere Tabelle, die dieses 64 MB Stück weiter aufteilt, z.B. in 1 MB Stücke. Und pro verwendetem 1 MB Stück hast du wiederum eine Tabelle die dieses 1 MB Stück in 4 KB Stücke aufteilt. "Leere" "Unter-Tabellen" werden dabei einfach weggelassen, der Zeiger in der übergeordneten Tabelle ist dabei einfach NULL.
-> der Page-Table ist sowieso schon nicht "eine Tabelle", also ist es IMO auch nicht schlimm noch pro Prozess einen eigenen anzulegen. Oder anders gesagt: es würde IMO nichts vereinfachen, sondern eher alles noch komplizierter machen.