Wie funktioniert Intel Paging wirklich?
-
Wie funktioniert das Intel Paging eigendlich wirklich? Die grundlagen, dass man über die lineare Adresse im PM einen Eintrag im paging Verzeichnis und tabellen angibt, sind mir schon klar. Aber der Sinn des Paging ist ja, dass man auch mit einem Selektor einen Beliebig großen Sektor (bis 4GB) beschreiben kann, der in wirklichkeit aus mehreren kleinen zusammengesetzt ist, also in wirklichkeit garnicht an einem stück existieren muss. Das wird ja alles hardwaremäßig gemacht. Man muss sich also nicht darum kümmern. Aber wenn ich das richtig sehe wird über die (virtuelle)lineare Adresse im Deskriptor auf eine bestimmte Paqe verwiesen. Wenn der Sektor aber größer ist als eine Page ist, woher weiß er in welcher page der zweite Tei des Sektrs steht?
-
mwoidt schrieb:
Aber der Sinn des Paging ist ja, dass man auch mit einem Selektor einen Beliebig großen Sektor (bis 4GB) beschreiben kann
Selektoren gehören aber zur Segmentierung, nicht zum Paging.
Aber wenn ich das richtig sehe wird über die (virtuelle)lineare Adresse im Deskriptor auf eine bestimmte Paqe verwiesen. Wenn der Sektor aber größer ist als eine Page ist, woher weiß er in welcher page der zweite Tei des Sektrs steht?
Ich galueb du vermischt Paging und Segmentierung ein bisschen
Also, es gibt aufm Intel 3 Sorten Adressen, virtuelle, lineare und physikalische. Wenn nun eien Adresse benutzt wird, geht das so:Das Programm benutzt eine virtuelle Adresse (Segment + Offset)
Anhand der GDT wird der Segmentdeskriptor rausgesucht (jaja, in wirklichkeit ist das im Cache im Prozessor), der Base-Wert wird zum Offset addiert und geguckt ob die Länge nicht überschritten wird. Man erhält dann die lineare Adresse.
Dann wird über das Page Directory (was über das Register CR3 adressiert wird) im Speicher die Seitentabelle gesucht. Dazu nimmt man die ersten 12 Bits der Adresse als Index in die PD-Tabelle. Dort fidnet man dann u.a. diie Adresse der Page Table, also geht man an die Adresse und findet eine weitere Tabelle. In der nimmt man die nächsten 12 Bits als Index und dort findet man schließlich die physikalische Adresse, an der schließlich die Daten liegen.Mit dem Selektor bezeichnest du also nur einen Bereich von linearen Adressen, die letztendlich erst über ein zweistufiges Tabellenwerk im Speicher in physikalische Adressen umgewandt werden
-
Ja aber was du da glaub ich übersiehst ist folgendes:
4096 byte ist eine page groß.
Im protected mode kann ein Segment 1Byte-4GB groß sein.Jetzt stellen wir uns vor wir haben im PM ein Segment-Diskriptor der ein segment von 1mb beschreibt (also das Segment ist größer als eine page). So jetzt greifen wir auf dieses Segment zu. Vom Prozessor wird jetzt die logische (virtuelle) Adresse in die physische Adresse umgewandelt. Das Segment auf das wir zugreifen ist aber größer als die Page. In der Page steht also der 1. teil des Segments. Woher weiß der Prozessor in welcher Page der 2. oder 3. Teil unseres 1mb Segments steht?
-
mwoidt schrieb:
Ja aber was du da glaub ich übersiehst ist folgendes:
4096 byte ist eine page groß.
Im protected mode kann ein Segment 1Byte-4GB groß sein.Keineswegs übersehen
Jetzt stellen wir uns vor wir haben im PM ein Segment-Diskriptor der ein segment von 1mb beschreibt (also der Sektor is größer als eine page). So jetzt greifen wir auf dieses Segment zu. Vom Prozessor wird jetzt die logische (virtuelle) Adresse in die physische Adresse umgewandelt.
Eben genau nicht. Da erst bekommen wir die lineare Adresse. Und die Adresse die da rauskommt wird jetzt erst mit Hilfe der Seitentabellen in eine physikalische übersetzt. Was du mit den Segmentdeskriptoren anstellst ist von den Pages vollkommen unabhängig, es sind zwei getrennte Übersetzungsmechanismen.
-
Das ging aber schnell!
Naja das war schlecht geschrieben zugegeben.
Also nochmal.
Der Sinn des Paging ist, dass der Hauptspeicher nicht fragmentiert und optimal genutzt werden kann.
So wir haben jetzt mal ein Segment im PM das 4096*2 byte groß ist (also genau 2 pages). So würde jetzt der Hauptspeicher aussehen:
|page1|page2|page3|page4|...
wir schreiben jetzt daten in unser Segment bis es voll ist. Die Daten müssen jetzt an die richtige stelle im Hauptspeicher. Der Prozessor rechnet mit hilfe des pagingverzeichnis und tabelllen die physikalische Adresse aus. Hier ist sie vielleicht 0h. Also page1 wird gleich mal von unserem Segment belegt. Jetzt sind aber mehr daten da als das Segment groß ist. Also schreibt der Prozessor wahrscheinlich auch noch mit in page2. Jetzt belegt unser Segment page1 und page2. In den tabellen ist jedoch nur page1 vermerkt. Das alleine führt ja zu keinem Problem, solang page2 nicht 2 mal benutzt wird. So jetzt wird zwischendurch page1 auf HD ausgelagert. Kein Problem. Jetzt wollen wir auf unser Segment wieder zugreifen. page1 ist ausgelagert, muss also wieder zurück in den speicher. Danach sieht unser Hauptspeicher etwa so aus
|page4|page2|page3|page1|
Wir wollen wieder unser komplettes Segment auslesen. Der Prozessor sieht das Segment liegt in page1. Page1 steht jetzt an folgender physischen adresse: ????h und dort müssen wir es auslesen. Wir sind jetzt am ende der page1 angelangt, das segment ist jedoch größer. Also sind da ja noch irgendwo daten von unserem Segment. Sie liegen noch in der page2, die immer noch ihren alten Platz hat. Woher weiß der Prozessor jetzt, das sie in page2 zu finden sind?
-
mwoidt schrieb:
Wir wollen wieder unser komplettes Segment auslesen. Der Prozessor sieht das Segment liegt in page1. Page1 steht jetzt an folgender physischen adresse: ????h und dort müssen wir es auslesen. Wir sind jetzt am ende der page1 angelangt, das segment ist jedoch größer. Also sind da ja noch irgendwo daten von unserem Segment. Sie liegen noch in der page2, die immer noch ihren alten Platz hat. Woher weiß der Prozessor jetzt, das sie in page2 zu finden sind?
Bei jedem Zugriff auf eine Page guckt der Prozessor (vom Caching abgesehen) in der Seitentabelle nach. D.h. solange du auf Adressen in page1 zugreifst, wird er die "hohen" Adressen rausrechnen, in dem Moment wo du auf die page2 zugreifst errechnet er die "niedrigen" Adressen. Nur weil die Pages scheinbar sequentiell in einem Segment liegen, müssen sie nicht fürs Paging auch hinetreinander liegen. Denn der Paging-Mechanismus weiß ja nichtmal mehr was von Segmenten und deren länge. Alles was das Paging macht, ist eine lineare 4GiB-Adresse in eine physikalische 4GiB-Adresse umzuwandeln. Und das wird für jede einzelne Adresse neu gemacht.
-
Ja genau aber funktioniert das? Wiso müssen die Pages nicht in der richtigen Reienfolge sein wenn mehrere Pages sequentiell zu einer "virtuellen großen"zusammengeschlossen sind? der Prozessor kann aus der Adresse die im Deskriptor liegt einen bewstimmten eintrag aus den pagingtabellen entnehmen. Eben nur einen. Er bräuchte aber logischerweise mehrere, da auch mehrere pages teile dieses segments beinhalten. Woher weiß er welche pages die richtigen sind? steht am ende der ersten page des sektors ein verweis auf die zweite?
-
mwoidt schrieb:
der Prozessor kann aus der Adresse die im Deskriptor liegt einen bewstimmten eintrag aus den pagingtabellen entnehmen. Eben nur einen.
Nein, nochmal, Segmentierung und Pagign sind zwei komplett unabhängige Dinge.
Wenn du mit Segmenten arbeitest wird ja einfach ein Base-Wert zu den Adressen addiert. Wenn du damit durch bist, schmeiß alles vom Segmentieren weg, nur diese Adresse zählt. Wie die Adresse dann zu ner physikalischen Adresse wird, regelt das Paging über ein vollkommen eigenständiges Tabellenwerk, vollkommen unabhängig von den Deskriptoren der Segmente. Dieses Tabellenwerk liegt irgendwo im Speicher.
-
Ahso so ist das. So hab ich das noch garnich gesehen.
Danke für deine Hilfe