
Nach Bryants und O'Hallarons (etwas abstrahiertem) Modell der Seitentabelle auf Linux-ähnlichen Systemen hat jeder Seitentabelleneintrag (PTE) ein Adressfeld, das einen von drei Werten enthält: (1) die physische Adresse (genauer gesagt die Seitennummer), der die virtuelle Seite zugeordnet ist; (2) eine entsprechende Standortkennung für ein Langzeitspeichergerät – wo die Seite gefunden werden kann; oder (3) 0 für eine nicht zugeordnete Seite. Angenommen, eine Seite wurde vom Langzeitspeicher in den Hauptspeicher ausgelagert. In dieser Darstellung ersetzt der Kernel die Langzeitspeicheradresse (2) durch die physische Adresse (1). Nehmen wir nun an, dass dieselbe Seite im physischen Speicher ausgelagert werden muss, um Platz für eine andere Seite zu schaffen. Wie wird die ursprüngliche Langzeitspeicheradresse in der PTE wiederhergestellt, wenn sie durch die physische Adresse überschrieben wurde? Danke.
Antwort1
PTEs repräsentierenvirtuellSeiten. Wie Sie sagen, wenn eine virtuelle Seite im Hauptspeicher vorhanden ist, enthält das Adressfeld des PTE die physische Seitenrahmennummer (PFN).
JedephysischSeite hat eine entsprechende struct page
. Diese hat:
Es folgt
flags
:struct address_space *mapping;
Bei Seiten, die sich im Seitencache befinden (ein großer Teil der Seiten auf den meisten Systemen),
mapping
verweist auf die Informationen, die zum Zugriff auf die Datei erforderlich sind, die die Seite sichert. Wenn es sich bei der Seite jedoch um eine anonyme Seite handelt (Benutzerspeicher, der durch Swap gesichert ist),mapping
verweist auf eineanon_vma
Struktur [...]--Mehr in die Strukturseite packen, LWN.net
Anschließend page→index
wird das Feld verwendet, um die swp_entry_t
Struktur für anonyme Seiten zu speichern. (Für Seiten im Seitencache enthält dies einen Dateioffset.)
swp_entry_t
enthält den Index des Auslagerungsgeräts und den Speicherort innerhalb dieses Auslagerungsgeräts.
Genauere Einzelheiten dazu, wie dies im Jahr 2004 funktionierte, finden Sie inDen Linux Virtual Memory Manager verstehen - Swap-Verwaltung, geschrieben von Mel Gorman.
Antwort2
mmap()
Aus Ihrer Frage geht für mich nicht ganz hervor, ob Sie nach PED-Dateien, Swap-Dateien oder passiv zugeordneten Dateien im Seitencache fragen , daher beantworte ich alle.
Im Nicht-MMAP-Fall ist Räumung Räumung: Sobald die Seite bereinigt ist, kann sie einfach gelöscht werden. Wenn eine Seite, die nicht durch eine Datei gesichert ist, aus dem Hauptspeicher verdrängt wird, ist es normalerweise nicht nötig, eine Adresse wiederherzustellen, da sie beim nächsten Zugriff auf die Datei einfach einen Seitenfehler in einen neuen Cache-Eintrag auslagert. Etwas Ähnliches passiert im Swap-Fall: Wenn wir einen Seitenfehler im Swap verursachen und später dieselbe Seite verdrängen müssen, geben wir beim nächsten Mal wahrscheinlich einfach eine neue Swap-Adresse an und legen diese im PTE fest (oder verwenden den Swap-Cache, wenn die Seite dort vorhanden und bereinigt ist).*
Im Fall von mmap wird der Lebenszyklus durch den mmap()
Systemaufruf gesteuert. Der Bereich wird explizit einem zusammenhängenden Teil des virtuellen Speichers zugeordnet mmap()
, und die Metadaten für diese Zuordnung (wie das zugrunde liegende FD, für das wir eine Referenzzählung haben, der Offset, die Größe usw.) werden im entsprechenden virtuellen Speicherbereich (VMA) gespeichert. Selbst wenn Seiten verdrängt werden, behält der VMA die Zuordnungsinformationen bei, sodass der Kernel weiß, von wo aus er beim nächsten Zugriff den Fehler melden soll.
* In Wirklichkeit finden weder Swapping noch allgemeine Paging-Aktivitäten normalerweise auf Seitenebene statt, sondern oft auf einer niedrigeren Granularitätsebene, wie etwa einem Swap-Cluster oder einem Readahead-Batch.