Diskussion:Virtuelle Speicherverwaltung

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

(FIFO)

Die Beschreibung von FIFO ist meiner Meinung nach falsch. Es muss doch gar nicht für jede Seite der Zeitstempel gespeichert werden, sondern pro Programm lediglich ein Zeiger der im Kreis durch den Speicherbereich läuft. Er zeigt immer auf die Seite, die als letztes eingelagert wurde. Muss eine neue Seite nachgeladen werden, wirft man also die Seite raus, auf die der Zeiger als nächstes zeigen würde, denn diese ist bereits am längsten im Speicher. Ich hoffe, das kam jetzt einigermaßen verständlich rüber. --Sharraz 18:08, 9. Dez. 2007 (CET)

Zusammenführung mit Paging

Ich denke, zumindest versteht man nun besser, was Paging mit Virtueller Speicherverwaltung zu tun hat. Ob man Paging nun überhaupt noch braucht, oder eine Weiterleitung reicht? --M-sch 17:13, 29. Feb. 2008 (CET)

Paging ist auch ohne virtuelle Speicherverwaltung möglich, deshalb sollte auch zu Paging selbst ein Artikel vorhanden sein.

Dieser muss natürlich entsprechend abgegrenzt werden und auf die virtuelle Adressierung als Anwendung verweisen. --RotzKotz_ere 12:49, 10. Jul. 2008 (CEST)

Swapping

Der Begriff "Swapping" wird in der Standardliteratur über Betriebssysteme (siehe z.B. Tanenbaum, Moderne Betriebssysteme, 2. Auflage, Pearson Studium, 2003, Kap.4) für die komplette Auslagerung eines Prozesses verwendet und nicht, wie im Artikel hier dargestellt, für die Auslagerung einzelner Seiten. Im Artikel über Paging ist das auch so dargestellt.

Das sehe ich (allerdings ohne Literatur) auch so! --Jkbw 21:20, 11. Okt. 2009 (CEST)

Frage zu NRU

Hi. Könnte folgendes bitte ein bisschen besser erklärt werden? Danke

" NRU („not recently used“): Teilt Seiten anhand des Use-Bits und Dirty-Bits aus der Seitentabelle in vier Klassen und entfernt zufällig eine aus der untersten, nicht-leeren Klasse. "

Welche ist denn die unterste und welches die oberste Klasse?

R=Referzbit M=Modifiedbit

R|M
0|0 die Oberste?
1|0
0|1
1|1

MfG Grey

Speicher-Überlastung

Liebe IP 62.178.226.83, der Begriff "Überlastung", auch das "Flattern" heißt "thrashing". Deine Version threshing ist keine Verbesserung des Artikels. LG Gerhardvalentin 21:12, 11. Okt. 2009 (CEST)

Segmentierung?

Mir scheint etw. einseitig dargestellt, dass virtueller Speicher durch Paging realisiert wird. Schließlich kann die Speichersegmentierung bzw. eine Kombination von Segmentierung und Paging ebenfalls eine Option sein zur Realisierung virtueller Speicher. (nicht signierter Beitrag von 91.64.181.174 (Diskussion) 00:51, 27. Jun. 2010 (CEST))

Stimmt, da sollte man mal aufräumen. Im Moment ist der Artikel z.T. grob falsch. :-( --RokerHRO 22:54, 27. Jun. 2010 (CEST)

Richtig, Segmentierung wird in dem Artikel völlig ignoriert. Nebst dessen das mit der Graphik zum 286 suggeriert wird das die Segmentierung im 32Bit-Mode der 386er gar nicht mehr vorhanden/nutzbar ist. Fakt ist natürlich auch das in den letzten 20 Jahren quasi kein Betriebssystem tatsächlich Segmentierung eingesetzt hat und das Segmentierung außerhalb der 32Bit-x86er (im 64Bit-Modus der x86er gibt es ebenfalls keine richtige Segmentierung mehr) bis auf ein paar kleine Ausnahmen nicht verfügbar ist, ein Betriebssystem das auf Segmentierung setzt wäre defacto nicht portierbar. Erik --193.159.161.200 16:07, 12. Sep. 2011 (CEST)

Platzierungsstrategien

Der Abschnitt passt nicht ganz rein. Mir ist nicht ganz wozu man hier eine "Lücke" suchen sollte: Wenn man Paging verwendet, gibt es doch keine Lücken, sondern nur freie Seiten. Und die müssen auch nicht am Stück frei sein, oder? --Ali (nicht signierter Beitrag von 85.49.147.197 (Diskussion) 13:52, 2. Nov. 2010 (CET))

Stimmt. Das Zusammenfassen von leeren Bereichen usw. mag vielleicht die Speicherverwaltung beschleunigenm, aber das hängt schon sehr von den verwendeten Algorithmen ab. Hab den Abschnitt daher erstmal auskommentiert. --RokerHRO 14:36, 2. Nov. 2010 (CET)

Diese Fit-Strategien beziehen sich meiner persönlichen Meinung nach auf den virtuellen Adressraum des Prozesses, das heißt wenn ein Prozess neuen Speicher in seinen virtuellen Adressraum haben will (beim OS anfordert) kann das OS sich eine passende Lücke im virtuellen Adressraum suchen wo dieser neue Speicher dann angelegt wird. An was für physischen Adressen die Pages liegen (welche in den virtuellen Adressraum reingemappt werden) ist dem Prozess völlig egal (hat auch keine Auswirkungen auf Performance o.ä., wenn man mal vom automatischen Zusammenfassen von kleinen Pages zu großen Pages zum Zwecke der TLB-Entlastung absieht). Erik --193.159.161.200 16:00, 12. Sep. 2011 (CEST)

korrekt, bezieht sich auf den virtuellen addressraum. kleine anmerkung, mit NUMA macht es inzwischen einen performance-unterschied wo die physikalischen pages hingelegt werden. gruesse Shaddim 12:34, 5. Dez. 2011 (CET)

Der ganze Abschnitt hat mit virtueller Speicherverwaltung nicht direkt zu tun, da es um Speicherverwaltung allgemein geht. Auch bei nicht-virtueller Speicherverwaltung muss das OS Strategien zur Speicherzuteilung anwenden.

Viel wichtiger fände ich, erst mal klarzustellen, dass auch der virtuelle Adressraum eines Prozesses vom OS gegenüber dem Prozess verwaltet wird (er muss anfordern und freigeben mittels OS-Calls), was ja durchaus nicht zwingend notwendig ist. Man könnte den Prozess auch einfach selbst machen lassen, und das OS kümmert sich erst, wenn ein Page-Miss eintritt (MMU-Trap "hinter der angeforderten virt.Page steht _keine_ reale Page").

Ich drohe mal wieder an, den entsprechenden Abschnitt entweder stark umzuformulieren, oder ganz zu löschen. --arilou (Diskussion) 14:03, 11. Jul. 2012 (CEST)

Artikelüberschneidungen

Kann vielleicht jemand mit Zeit und Sachverstand die erheblichen Überschneidungen mit Paging auflösen? --Trickstar 15:17, 29. Apr. 2011 (CEST)

Nicht-Auszulagerndes

Im Artikel wird nicht darauf eingegangen, dass evtl. ein virtueller Adressbereich eines (bestimmten) Prozesses gar nicht ausgelagert werden darf. Ich denke da an "Userland/Userspace Driver" und ähnliches, wobei ein Treiber als normales Programm im User Mode läuft, aber nicht ausgelagert werden darf.

Eventuell gibt's auch ähnliches in einem Echtzeit-OS, dass ein Prozess nicht ausgelagert werden darf, obwohl er länger nichts gerechnet hat.

--arilou (Diskussion) 18:16, 29. Apr. 2012 (CEST)

Speicherfragmentierung, Beispiel "DOS"

Bei einem Single-Tasking-OS ist nach jedem (beendeten!) Prozess der anfänglich freie Adressraum wieder genauso frei und unfragmentiert, wie beim Start des vorigen Prozesses. Lediglich Treiber und TSRs als "nicht korrekt beendete Prozesse" machen evtl. Probleme.

DOS ist ein schlechtes Beispiel. Wie wär's stattdessen mit AmigaOS ? Multitasking (mehrere "normale" Prozesse gleichzeitig), aber kein virtueller Speicher. Passt viel besser - allerdings weis ich nicht, welche Strategien hier OS-seitig zur Fragmentierungs-Vermeidung eingesetzt wurden. Gibt's hier Spezialisten?

--arilou (Diskussion) 10:16, 16. Jul. 2012 (CEST)

hmm, ja das wäre interessant wie (und ob) AmigaOS dieses Problem behandelt. Ich weiss es nur von DOS und den iterativen Speicheroptimieren. gruesse Shaddim (Diskussion) 19:13, 17. Jul. 2012 (CEST)

Die aber (wie gesagt) nur optimieren, in welcher Reihenfolge Treiber und TSRs sinnvollerweise geladen werden.

Hat nix mit normalen Anwendungen zu tun.

--arilou (Diskussion) 14:32, 1. Jul. 2013 (CEST)

Abschnitt "Beispiele"

"AMD64-Architektur: Eine virtuelle Adresse ist 48 Bit lang."

Das ist -hm- eigentlich falsch. Die virtuelle Adresse ist (aus Prozess-Sicht) 64 Bit groß. Bei aktuellen AMD-Chips müssen die höchsten 16 Bit aber Nullen sein (00_hex), da deren Hardware/MMU/Pagetables nur 48-Bit virtuelle Adressen abbilden können. Zukünftige Hardware macht aber vielleicht 50, 52 oder noch mehr Bits, d.h. ein Prozess muss von 64 Bit ausgehen - die virtuelle Adresse ist also 64 Bit.

--arilou (Diskussion) 10:23, 16. Jul. 2012 (CEST)

korrekt, die Adressen sind 64bit, die Bitbreite des implemntierte Addressraums sind aktuell weniger. Shaddim (Diskussion) 19:13, 17. Jul. 2012 (CEST)

Ursache für zunehmende OoM-Fehler

Abschnitt "Speicherfragmentierung":

Version von Shaddim: "Dies trat in den 2000ern am Ende der 32-Bit PC-Ära als praktisches Problem auf, der virtuelle Adressraum war nicht mehr signifikant größer als der typische physikalische RAM-Ausbau."

Das sehe ich nicht als eigentliche Ursache des Problems, sondern:

"Dies trat in den 2000ern am Ende der 32-Bit PC-Ära als praktisches Problem auf: Zunehmend verlangten Anwendungen Ram-Mengen in ähnlicher Größe wie der virtuelle Adressraum, da der typische physikalische RAM-Ausbau entsprechend groß war."

Argumentation also: Weil (1.) in vielen PCs 1..4 GB Ram stecken, werden (2.) Anwendungen programmiert, die entsprechend viel Ram verwenden, was (3.) zu einem dicht-gefüllten 32-Bit-virtuellen Adressraum führt mit entsprechenden OoM-Fehlern.

Wenn (a) in einem Rechner 4 GB Ram stecken und (b) der virt.Adressraum 32 Bit ist, die Prozesse aber nicht selbigen Adressraum ausreizen (nicht_c), dann gibt's auch keine OoM-Fehler. (c) ist zwingende Vorbedingung.

(Und genaugenommen ist (1.) keine Vorbedingung, da die Fragmentierung des virtuellen Adressraums auch zu OoM führt, wenn nur wenig phys.Ram da ist und geswappt wird.) --arilou (Diskussion) 12:13, 19. Jul. 2012 (CEST)

der Argumentationslinie 1.) -> 2.) stimme ich zu. Meine weitergehende Argumentation ist jedoch das wenn beide Adressräume ähnlich gross sind, der virtuelle Adressraum zunehmend seine Fähigkeit der "(laufzeit)Defragmentierung" verliert, d.h. erstmalig überhaupt OoM-aufgrund der Fragmentierung auftreten, also BEVOR der physikalische/virtuelle Speicher "wirklich", absolut ausgeht. Beim Fall 1GB RAM/Swap (maximalgrösse beide zusammen!) und 4GB virtueller Speicher tritt der OoM höchstwahrscheinlich erst bei wirklichem, absolutem OoM auf, OoM aufgrund Fragmentierung des virt. Speichers tritt nicht auf. gruesse Shaddim (Diskussion) 15:32, 19. Jul. 2012 (CEST)

PS: Oder auch andersherum formuliert: ist der virtuelle Addressraum deutlich grösser als der physikalische kann 100% des physikalischen Speichers verwendet werden bevor es zu OoM kommt. Sind sie zunehmende ähnlich gross kann dies schon deutlich früher auftreten, im Extremfall bei sehr grossen Blockallokierungen schon bei 0% (eigentlich alles frei) z.B. bei einem malloc von 1,6GB am Stück es aber nur 1,5GB grosse Blöcke gibt (durch DLLs) bei 2GB freiem Speicher (siehe matlab). Shaddim (Diskussion) 15:38, 19. Jul. 2012 (CEST) PPS: siehe auch Beispiel weiter oben in der Diskussion. Shaddim (Diskussion) 15:40, 19. Jul. 2012 (CEST)

Totaler Quatsch. Eine Anwendung, die zB 1.5 GB "am Stück" allokieren will (virtuelles Ram), kann das problemlos bekommen, auch wenn im realen Ram jede 4k-Page einzeln zugeordnet werden muss (also im realen Ram gar nichts mehr "am Stück" ist).

--arilou (Diskussion) 14:30, 1. Jul. 2013 (CEST)

Geschichte

Man kann doch die Geschichte nicht auf Güntsch reduzieren (mal abgesehen davon, dass auch zu berücksichtigen ist, welchen internationalen Einfluss Günsch damit hatte), die Notwendigkeit externe Speichermedien einzubeziehen führte doch auch bei anderen Computerprojekten der 1950er Jahre zu ähnlichen Konzepten. Man vergleiche den historischen Abschnitt in der engl. wiki. en:Virtual Memory--Claude J (Diskussion) 08:49, 18. Nov. 2012 (CET)

Habe das entsprechend erweitert (Hauptquelle Denning).--Claude J (Diskussion) 09:34, 18. Nov. 2012 (CET)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://cs.gmu.edu/cne/pjd/PUBS/ecs.pdf
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 403)http://giftbot.dwl.invalid/http://cs.gmu.edu/cne/pjd/PUBS/ecs.pdf
  • Artikel mit gleicher URL: David Sayre (aktuell)
• http://cs.gmu.edu/cne/pjd/PUBS/bvm.pdf
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 403)http://giftbot.dwl.invalid/http://cs.gmu.edu/cne/pjd/PUBS/bvm.pdf
• http://www.cs.gmu.edu/cne/itcore/virtualmemory/vmhistory.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Problem mit Ressource (HTTP-Statuscode 403)http://giftbot.dwl.invalid/http://www.cs.gmu.edu/cne/itcore/virtualmemory/vmhistory.html

– GiftBot (Diskussion) 05:27, 28. Nov. 2015 (CET)

Dein Revert bzgl. "Virtuelle Speicherverwaltung"

Hierher verschoben von Benutzer:Arilou's Disku-Seite, da Artikel-bezogene Diskussion. // --arilou (Diskussion) 09:41, 22. Jul. 2019 (CEST)

Der Punkt den du m.E. fälschlicherweise wiederhergestellt hast, ist "Copy-on-Write". Natürlich wird dann der Code physikalisch nur einmal im Speicher gehalten, wenn du xterm gerade mehrfach fährst, aber das Programm muss trotzdem jedes Mal gebunden werden (ldd `which xterm`). Das sharing, um das es geht, wird im Rahmen des Mappings erzeugt. Siehe z.B. [1] für eine Zusammenfassung des Vorgangs. Wo soll denn da bitte dein Copy-on-Write stattfinden? -- Cobalt pen (Diskussion) 12:39, 21. Jul. 2019 (CEST)

Wenn von einem Prozess (ggf. auch vom OS selbst) irgend etwas (Programm, Bibliothek, Datenfile, ...) angefordert wird, lädt das OS erst einmal gar nichts davon von der Festplatte, es lädt nur den zugehörigen iNode und vermerkt in der Page Table des anfordernden Prozesses einen entsprechend großen Adressbereich - als "swapped out". Sind Pages des "Datenobjekts" bereits im Ram (und als "unverändert" gekennzeichnet), dann können die entsprechenden Page-Table-Einträge darauf zeigend gesetzt werden und als "swapped-in, non-private" markiert werden; afaik ist "non-private" als Default gesetzt, wenn ein Prozess erstmals ein Datenobjekt öffnet. Sobald ein Prozess an dem Datenobjekt irgend etwas ändern will (in eine Page schreiben möchte, die als 'non-private' markiert ist), würde er für alle die Daten ändern. Dann wird die Page kopiert ("Copy-on-Write"), er bekommt eine "private" (markierte) Page, und darin darf der Prozess ändern wie und was er will.

Das ist alles komplett unabhängig davon, ob es sich um eine DLL, einen Datenfile, Programmcode oder sonstwas handelt. Das OS braucht auch keinerlei Information darüber, ob etwas "Variablenbereich", "pre-filled Stack" oder sonstwas ist.

Außerdem ist es extrem einfach,

• Programmcode zu schützen (NX-Bit) - da (der erste) Schreibzugriff(e) ja bemerkt wird, kann eine Page als 'NX' markiert sein, dann wird das Schreiben verweigert (und i.A. der Prozess abgebrochen);
• Prozess-gemeinsames Ram (IPC) wird nicht kopiert und bleibt 'non-private', wenn ein (berechtigter) Prozess darauf schreiben will.
• Es wird nichts unnötigerweise von HDD geladen - greift der Anforderer nur auf Teile des Datenobjekts zu, werden auch nur diese von der HDD 'swapped-in'.

Das Laden einer DLL oder eines Programms ist thematisch schon "eine Stufe höher", es baut "obendrauf auf". Das "Copy-on-Write" gehört zum absoluten Low-Level-Virtual-Memory-Management.

Afaik arbeiten alle aktuellen OSs mit derartigem "lazy loading" und "Copy-on-Write".

--arilou (Diskussion) 09:56, 22. Jul. 2019 (CEST)

Hmm, da du auch von "Datenfile"s sprichst, gehen wohl Caching, Mapping und virtueller Speicher durcheinander. Ich versuche das mal auseinander zu bringen:

* Ein Programm wird vor der Ausführung in jedem Fall erst einmal "geladen" und gebunden.

* Das "Laden" findet über ein Mapping statt, das eine gemeinsame Verwendung von Seiten ermöglicht.

* Hierbei wird, wenn sich die Seite schon im Hauptspeicher befindet und schreibgeschütz ist, diese einfach zwischen den Prozessen geteilt.

* Für Code ist dies in jedem Fall gegeben.

* Die schreibbaren Bereiche sind immer privat und werden ggfls. bereits während des Bindens geändert.

* Hier könnte der Binder über mmap/MAP_PRIVATE die Orginal-Seite in der Tat über Copy-on-Write einfügen, wenn das Orginal noch im Cache vorliegt.

* Ansonsten würde diese erst über einen Seitenfehler von der Platte (aus der Programm- oder Library-Datei) nachgeladen.

* Für ELF wäre dies z.B. die Sektion ".data", in der sich initialisierte, schreibbare Daten befinden.

1) Der Fokus liegt an dieser Stelle im Artikel aber auf dem "Virtuellen Speicher pro Prozess". Die ist virtueller Speicher im engeren Sinne. Der Cache, aus dem dein Copy-on-Write stattfinden soll, ist gar nicht im Bild.

2) Die fraglichen schreibbaren Seiten würden aber aus denen des Prozesses bei einem clone mittels Copy-on-Write geteilt.

Das "automatische Copy-on-Write", wie es von dir im Text gesetzt ist, legt ein Kopieren der Seiten wie in 2) also aus dem Speicherabbild des Prozesses nahe, was bei einem Programmstart natürlich nicht geht. Hier spielt dann der Cache eine Rolle. Der Seitentauscher (dein "absolutes Low-Level-Virtual-Memory-Management") arbeitet natürlich eng mit dem Cache zusammen und kann auch Teile des geladenen Codes einfach verdrängen, ohne erst ihn in eine "Auslagerungsdatei" schreiben zu müssen. Er ist ja schon auf der Platte. Die Vorstellung, die im Artikel vom "Swapping" als "Auslagerungsdatei" vorgestellt werden, stimmen so gar nicht.

Sind wird da inhaltlich nun zusammen, ariloo, und was heißt das für den Artikel bzw. die fragliche Stelle? -- Cobalt pen (Diskussion) 13:40, 22. Jul. 2019 (CEST)

Ich glaube, das Einfachste wäre wohl, den fraglichen Absatz einfach zu streichen.

Ansonsten müsste man wohl den Artikel insgesamt dahingehend etwas überarbeiten, dass die verschiedenen Themen klarer getrennt werden.

Etwa virtueller vs. physikalischer Adressraum vs. Festplatte, MMU, Seitenfehler, Seitentauscher, Cache vs. Swap.

Das Zusammenwirken zwischen Hauptspeicher und Festplatte wäre zu ergänzen, da es völlig fehlt. Der Abschnit "Swapping" deckt dies m.E. nicht ab und ist fehlleitend.

-- Cobalt pen (Diskussion) 12:38, 24. Jul. 2019 (CEST)