Diskussion:Virtuelle Speicherverwaltung/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Falsches Lemma

Die sogenannte "virtuelle" Speicherverwaltung ist überhaupt nicht virtuell, sondern nur deren Speicher! -- Pollux ★ 21:33, 10. Dez. 2007 (CET)

Tja, dieses Problem hat man immer, wenn man englische Begriffe, bestehend aus Adjektiv + Substantiv + Substantiv, mit der logischen Kopplung (A+S) + S übersetzen will, wenn in der deutschen Übersetzung dann die beiden Substantive zu einem Kompositum verschmelzen und damit die logische Kopplung sich ändert zu A + (S+S). :-(
In diesem Falle ist "Virtuelle Speicherverwaltung" aber eine durchaus übliche Übersetzung. Würden wir hier einen anderen Begriff verwenden, wäre das WP:TF. Und ich denke, wer mit diesem Fachbegriff nicht kennt, dem wäre auch mit "Virtualspeicher-Verwaltung" od.Ä. nicht geholfen. Und wer diesen Begriff kennt und weiß, was er bedeutet, der stört sich auch nicht mehr an der unglücklichen Übersetzung. --RokerHRO 22:30, 11. Okt. 2009 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:33, 11. Jul. 2012 (CEST)

Virtueller Adressraum und Virtuelle Speicherverwaltung

Sollte man die beiden Artikel nicht vereinigen? -- Essen-thomas 16:01, 11. Feb 2006 (CET)

Erledigt. -- ReqEngineer Au weia!!! 19:03, 25. Dez. 2006 (CET)

Hier die Beitragenden von Virtueller Adressraum:

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:32, 11. Jul. 2012 (CEST)

dito Virtuelle Adresse

-- ReqEngineer Au weia!!! 19:31, 25. Dez. 2006 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:33, 11. Jul. 2012 (CEST)

Grammatik letzter Satz unter "Motivation"

Hallo, ich meine der Letzte Satz unter "Motivation" macht grammatikalisch keinen Sinn, siehe "Funktionieren". Da mein Fachwissen nicht ausreicht um diesen Beitrag zu bearbeiten wollte ich nur kurz darauf aufmerksam machen.

MfG (nicht signierter Beitrag von 141.41.254.6 (Diskussion) 10:31, 29. Jan. 2012 (CET))

hmmm, ich glaube es ist korrekt aber sehr schwer zu verstehen mit den beiden geklammerten einschüben... zerlegen in 2 Sätze? Shaddim 16:07, 7. Feb. 2012 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:31, 11. Jul. 2012 (CEST)

Virtuelle Speicherverwaltung des Anwenders

Neben der ganzen Theorie gibt es ja auch noch die praktische Seite einer Virtuellen Speicherverwaltung. Der fortgeschrittene PC Benutzer kann seine virtuelle Speichergröße im Bereich Einstellungen manuell einstellen bzw. verändern. Gibt es hierfür eine Richtlinie , wie die virtuelle Speichergröße optimal einzustellen ist ? Das System schlägt meist eine relativ grosse Speicherplatzreservierung für den virtuellen Speicher vor - geht das zu Lasten der Verarbeitungsgeschwindigkeit? Anders gefragt : Welche Speichergrösse wäre denn das Minimum für den virtuellen Speicher ? Ing MiBo 25.04.2012 (nicht signierter Beitrag von 87.162.205.99 (Diskussion) 19:05, 25. Apr. 2012 (CEST))

Was du meinst ist die Größe der Swap-Datei (unter Win "Auslagerungsdatei" ~ also bitte etwas genauer lesen, was Windoof anzeigt...). Eine Empfehlung ist schwierig; für Arbeitsplatz-Rechner eher wenig (oder gar nichts): Wenn der Rechner ins Swappen gerät, beendet man einfach ein Programm und macht seine Arbeit eben nacheinander statt gleichzeitig. Für einen Server, der (unbetreut) stabil rechnen soll, eher eine große Auslagerungsdatei (bis zum 4-fachen des physikalisch vorhandenen Rams). Er wird dann schnarch-lahm, aber arbeitet weiter und lehnt keinen Auftrag ab ("Out of memory"). --arilou (Diskussion) 18:10, 29. Apr. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:28, 11. Jul. 2012 (CEST)

Abschnitt "Funktionsweise"

"Beim Zugriff eines Prozesses auf eine lokale Speicheradresse ersetzt das Betriebssystem diese durch eine virtuelle, welche von der Memory Management Unit des Systems in die aktuelle physische Adresse umgesetzt wird."

Was ist hier bitte mit "lokale Speicheradresse" gemeint?!? Dass das OS eine solche "lokale" ersetzen würde zu einer "virtuellen", ist mir neu, und ich wage zu behaupten: Es ist (in aktuellen Rechnern) schlicht falsch. --arilou (Diskussion) 09:38, 10. Jul. 2012 (CEST)

Hab' den Abschnitt mal deutlich überarbeitet. --arilou (Diskussion) 09:44, 10. Jul. 2012 (CEST)
mit lokal war wohl im aktuellen, lokalen (Prozess-)Kontext gemeint. gruss Shaddim (Diskussion) 19:24, 10. Jul. 2012 (CEST)
Eine "Adresse im (lokalen) Prozesskontext" ist eine virtuelle Adresse, und muss nicht "vom Betriebssystem durch eine virtuelle ersetzt" werden. Mittlerweile hab' ich diesen Humbug ja verbessert. --arilou (Diskussion) 09:26, 11. Jul. 2012 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 09:26, 11. Jul. 2012 (CEST)
Ich denke gemeint war: das programm greift auf eine Adresse im lokalen Prozesskontext zu, es weiss weder ob diese virtuell physikalisch oder was auch immer ist, es ist einfach eine Adresse. Denke das hier versucht wurde den Bedeutungsübergang anzudeuten, von abstrakter Prozesssicht zu technsicher Umsetzung über virtuelle und physikalische adressräume. gruesseShaddim (Diskussion) 12:11, 11. Jul. 2012 (CEST)

Fehler

fehler in Satz "in Seitenfehler (engl.: page fault) tritt auf, wenn ein Programm auf eine Seite zugreift, die sich gerade nicht im Hauptspeicher befindet, sondern ausgelagert wurde Programmunterbrechung (engl.: trap) aus." , bitte beheben (nicht signierter Beitrag von 93.129.139.124 (Diskussion) 21:55, 25. Sep. 2012 (CEST))

(neuer Beitrag nach unten verschoben --arilou (Diskussion) 10:07, 26. Sep. 2012 (CEST))
1. Danke für den Hinweis
2.
Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 10:10, 26. Sep. 2012 (CEST)

Motivation, warum bei größerem virt. Adressraum ?

"Eine weitere nützliche Eigenschaft des virtuellen Adressraums ist die Möglichkeit, Speicherfragmentierungen zu kaschieren, insbesondere wenn der virt. Adressraum deutlich größer ist als der physikalische Speicher."

Wenn ich das mal spitzfindig lese, dann steht da:

"Wenn der virtuelle Adressraum deutlich größer ist als der physikalische Speicher, dann kann VMM eine Speicherfragmentierung kaschieren, die ohne VMM ein Problem wäre."

Ohne VMM gäb's aber auch keinen virtuellen Adressraum, oder? Und wie könnte dieser nicht-existend dann noch größer als der physikalische Speicher sein?

Außerdem ist Speicherfragmentierung innerhalb eines Prozesses in dessen Adressraum genauso möglich bei virtuellem Adressraum wie bei nicht-virtuellem. Will sagen: Unter dem Nur-Ein-Prozess-OS DOS hat ein Anwendungsprogramm mit Speicherfragmentierung zu kämpfen. Ein Prozess unter WinXX/Linux/MacOS muss innerhalb seines (virt.) Adressraums genauso mit Speicherfragmentierung kämpfen. Aus Prozesssicht ist da nichts gewonnen.

--arilou (Diskussion) 11:01, 26. Jun. 2012 (CEST)

Die Antwort wird deutlich beim kürzlich erfolgten 32-/64Bit Wechsel. Wenn in einem 64-Bit System 2GB RAM stecken wird eine Speicherfragmentierung (und damit potentielle Out-of-memorys) effektiv verhindert dadurch das die 2^31Bit physikalischen Bits sich in 2^40Bit (CPU implemnetierte) virtuellem Speicher weitläufig verteilen und bessere Speicherbereichswahlen möglich sind. Deutlich mehr Platz, also Fragmentierung unwahrscheinlich und vermeidbar. Bei 32 Bit Systemen wo diese 2^31Bit physikalischer Speicher in 2^32Bit virtuellem Speicher unterbracht werden müssen, ist eine Fragmentierung und späteres Out-of-memory (trotz physiklaischem Speicher) kaum zu vermeiden, einfach kein Platz für geshcickte Bereichs Wahl. Bzw. wenn der physiklaische Speicher 1-1 auf virtuellen Speciher abgebildet wird (also beide gleich oder ähnlich gross sind), ist der "weniger Fragmentierung"-Vorteil von virtuellem Speicher bei dynamischer Speicherallokierung und -deallocierung nicht vorhanden. Falls eine bessere Formulierung gefunden würde wäre ich froh ;) gruesse Shaddim (Diskussion) 00:42, 7. Jul. 2012 (CEST)
Soweit ich das sehe, hat eine Speicherfragmentierung im virtuellen Adressraum der Anwendung gar nichts mit dem realen Ram zu tun und kann daher im realen Ram auch keine Vor-/Nachteile verursachen. Dass ein großer (virtueller) Adressraum einen Out-of-Memory-Fehler hinauszögert, ist eine Binsenweisheit.
Selbst wenn die Anwendung in ihrem virtuellen Adressraum nur einen einzigen, langen Speicherbereich "am Stück" anfordert und verwendet (also maximal "unfragmentiert"), sagt das gar nichts darüber aus, ob die entsprechenden realen Pages ebenfalls hintereinander liegen, oder komplett durcheinandergewürfelt sind.
Hm, was jedoch stimmt ist: Wenn ich eine gegebene Anwendung habe, die stark Speicher-fragmentierend agiert, würde diese im nicht-virtuellen Ram relativ schnell an ihre Grenzen stoßen. Das VMM kann u.U. dabei helfen, dass die Anwendung nur soviel (echtes) Ram belegt, wie sie tatsächlich benötigt; durch den (evtl.) deutlichen größeren virtuellen Adressraum stößt die Anwendung erst später an ihre Grenze. Entstandene ungünstige "Leerräume" im virtuellen Adressraum "blendet die VMM dann weg" und teilt ihnen kein reales Ram zu (unter der Annahme, dass die durch Speicher-Fragmentierung entstandenen "Löcher" größer als eine Page sind und sich dadurch ganze Pages sparen lassen).
Nur kenn' ich kein OS, bei dem erst "ohne VMM", dann "mit VMM" gewesen wäre, sodass tatsäch ein und dasselbe Programm von diesem theoretischen Vorteil hätte profitieren können.
In diesem Zusammenhang ist die Umstellung 32-64 Bit zwiespältig: Einerseits vergrößert sich der virtuelle Adressraum, was (theoretisch) dieser schlechten Anwendung mehr Platz verschafft; andererseits wachsen i.A. die Page-Größen von 4 kB auf 4 MB, womit "Lücken" viel weniger granular "ausgeblendet" werden können, sodass der reale Ram-Bedarf stark ansteigen kann, und das System (vor der 32-64 Umstellung 2GB Ram, danach ebenfalls) deutlich schneller ins Swappen gerät...
--arilou (Diskussion) 09:35, 9. Jul. 2012 (CEST)
Sorry denke da übersiehst du was, es gibt einen negativen Einfluss des virtuellen Speicher auf den physikalischen Speicher. Wenn ein Programm einen grossen Speicherblock anfordert der grösser als der grösste unfragmentiertet Block virtuellen Speichers ist kommt es zum out-of-memory, selbst wenn noch genug physikalischer Speicher (RAM) oder Swap-Speicher verfügbarist, egal ob dieser fragmentiert oder nicht ist. D.h. der virtuelle Speicher wird selsbt zur Quelle von Speicerhfragmentierungsproblemen anstelle dieses Problem für den physikalischen Speicher zu lösen. Dieses Problem wird dann kritisch wenn virtueller Speicher ungefähr so gross wie der physikalische Speicher ist, was bei 32Bit system heute häufig der Fall ist. gruesse

PS: siehe zB hier für matlab, grösster verwendbarer speichrblock begrenzt durch den virtuellen speicher(http://www.mathworks.de/help/techdoc/matlab_prog/brh72ex-49.html): 

 Maximum possible array:             583 MB (6.111e+008 bytes) *
 Memory available for all arrays:   1515 MB (1.588e+009 bytes) **
 Memory used by MATLAB:              386 MB (4.050e+008 bytes)
 Physical Memory (RAM):             2014 MB (2.112e+009 bytes)
 *  Limited by contiguous virtual address space available.
 ** Limited by virtual address space available.

Shaddim (Diskussion) 21:01, 9. Jul. 2012 (CEST)

"Dieses Problem wird dann kritisch wenn virtueller Speicher ungefähr so gross wie der physikalische Speicher ist, was bei 32Bit system heute häufig der Fall ist." - Das ist eine Behauptung, die du bisher nicht begründet hast. Und die ich anzweifel.
Und dass virtueller Speicher das Fragmentierungsproblem nicht löst, sondern gar keinen Einfluss darauf hat (außer es evtl. etwas hinauzuzögern, s.o.), ist mein Standpunkt, also bitte.
--arilou (Diskussion) 09:14, 10. Jul. 2012 (CEST)
Annahme: Ich habe ein Programm, das aufgrund Speicherfragmentierung in Out-of-Memory (OoM) läuft. Ich gebe ihm 4GB reales Ram (kein VMM, einfach flach adressiert, komplett frei). Dann läuft es an einem bestimmten Punkt in den OoM-Fehler.
Setz' ich unter das Programm eine VMM mit 4GB virtuellen Adressraum, ändert sich gar nichts, es stürzt genau an der selben Stelle ab. Das Problem Speicherfragmentierung ist unabhängig von VMM.
Biete ich dem Programm einen virtuellen Adressraum von 16 GB, so läuft es länger, bis es abbricht.
Bei realen 16 GB (ohne VMM) wäre es auch länger gelaufen, und wiederum an der selben Stelle abgebrochen.
Fazit: Einzig die Größe des Adressraums hat Einfluss, und kann hinauszögern. Lösen kann VMM ein Fragmentierungsproblem nicht. --arilou (Diskussion) 09:57, 10. Jul. 2012 (CEST)
Das ist inkorrekt. Die VMM beinflusst das Speicher-Fragmentierungsverhalten signifikant und ist einer der Nutzeffekte solange der physikalische Speicher eine grössenordnung kleiner ist als der virtuelle speicher (was üblicherwiese der Fall ist, der virtuelle Speicherraum wurde bei designlegung immer signifikant grösser als der zu virtuallisierende adressraum angelegt, aus genau diesem Grund). Mit einem 64Bit system und 40Bit virtuellem Speicherraum und angenommenen 32Bit physiklaischem Speicher ist rein statistisch eine Fragementierung praktisch ausgeschlossen. Für den Fall 32Bit virtueller Speicher und 32Bit pyhsikalischer Speicher sind fragmentierungseffeke kaum zu vermeiden, sogar mit dem irritierenden Fall das bei sogar unfragmentierten physikalschem Speicher die Fragmentierung des virtuellen Speichers zu "out-of-memory" führt. Shaddim (Diskussion) 11:26, 10. Jul. 2012 (CEST)
zu deinem Anwendungsbeispiel(en): da der fragmentierungszustand (sowhl pyhsikalischer als auch virtueller) systemabhängig, prrogramm- und auch nicht-determinsitsch ist, sind Out-of-memory Abbrueche nicht so einfahc zu postulieren. Bei der von dir angenommenen 1-1 grösse des virtuellen speichers zu physiklaischen Speichers kann je nachdem wie wild das Programm malloc und free (mit verschiedenen speichergrössen) einsetzt die Abstraktion durch den viruellem speicher zu einem früheren Abbruch als bei der reine physikalischen varianante führen (zusätzliche fragmentierung des virt.-speichers). Bei einem Programm mit rein sukkzessiven mallocs ohne free (keine fragmentierung durch das programm) sollte im virtuellen Speichersystem das Programm länger mit Speicher versorgt werdne können als die rein physikalische. Gleiche Addressraumgrössen unterschiedliches Verhalten. Der Punkt das die Grösse des Speicheradressraums wichtig ist, ist korrekt, zu beachten ist hier jedoch das diese Grösse für den physikalischen und virtuellen Speicher sehr unterschiedlich sein können (und typischerweise mit gutem Grund auch sind), was zu anderem Fragmentierungsverhalten führt. gruesse Shaddim (Diskussion) 11:45, 10. Jul. 2012 (CEST)

Ich hab' mal auf Wikipedia:Dritte Meinung#Artikel Virtuelle Speicherverwaltung angefragt, ob noch jemand hier mitreden könnte. Ich hab' etwas das Gefühl, dass wir aneinander vorbei reden - oder eigentlich dasselbe meinen, aber verschieden ausdrücken. --arilou (Diskussion) 13:30, 10. Jul. 2012 (CEST)

Ich sehe das so: Durch den virtuellen Adressraum stellt eine Fragmentierung des physikalischen Adressraums kein Problem mehr dar, da ein Bereich der virtuell zusammenhängend ist nicht zwingend physikalisch zusammenhängen muss. Problematisch ist hier nur noch eine Fragmentierung des virtuellen Adressraums. Diese ist aber in jedem Fall ein geringeres Problem, da der virtuelle Adressraum jedem Prozess exclusiv zur Verfügung steht und darüber hinaus meistens auch noch sehr viel größer ist.--Trockennasenaffe (Diskussion) 13:56, 10. Jul. 2012 (CEST)
Um es mal zusammenzufassen: Der virtuelle Adressraum verhindert keine Fragmentierung. Er sorgt aber dafür, dass das Problem der Fragmentierung weniger praxisrelevant wird.--Trockennasenaffe (Diskussion) 14:28, 10. Jul. 2012 (CEST)
Hm (ich hatt' das Problem vor einiger Zeit halt mal konkret), wenn ich ein Programm habe, das (aufgrund scheußlicher Programmierung) ein Fragmentierungsproblem hat, ganz alleine und einfach aus-sich-selbst, dann ist es egal ob ich ihm 4 GB realen Speicher (flach, exklusiv, leer) anbiete und es nach xxx mallocs in OoM rennt, oder ob ich ihm 4 GB virtuellen Speicher (virtuell, flach, exklusiv, leer) gebe - es rennt nach genau denselben xxx mallocs in den OoM-Error. D.h. das Virtualisieren hat dem Programm gar nichts gebracht.
Was ihm etwas bringt, wäre, wenn es statt 2^32 Byte Adressraum (zuvor/real) nun 2^64 Byte hat (danach/virtuell); es betreibt zwar immernoch heftigst Fragmentation, rennt aber erst nach yyyyy mallocs in den Error. Das wäre aber genauso, wenn ich dem Programm 2^64 Byte reales Ram anbieten könnte, es behebt also nicht (direkt) die Fragmentierung. Das Problem wird nur hinausgeschoben/verzögert.
Tatsächlich kann die Pagetable dabei dafür sorgen, dass große Lücken im fragmentierten virtuellen Ram zumindest kein reales Ram belegen, und das Programm tatsächlich relativ lange sein fragmentierendes Spiel im virt.Adressraum fortsetzen kann. (Was aber nichts daran ändert, dass der virt.Adressraum fragmentiert ist.)
Der eigentliche Benefit ist also weniger die Virtualisierung, sondern der sehr viel größere Raum. Wäre es v.a. die Virtualisierung, dann müsste ein signifikanter Vorteil schon entstehen, wenn man aus 32-Bit(real) 32-bit(virtuell) machen würde, was aber ja nicht der Fall ist.
--arilou (Diskussion) 14:50, 10. Jul. 2012 (CEST)


Die Virtuallisierung verhindert das Fragmentieren des Adressraums (in dem Fall der virtuelle Adressraum) natürlich nicht. Der Vorteil entsteht insbesondere durch den größeren nutzbaren Adressraum. Dieser ist in aber in der Praxis praktisch immer gegeben. Wenn der virtuelle und der reale Adressraum gleich groß ist, und man keinerlei Multitasking einsetzt, macht auch Paging keinen Sinn. Bei Multitasking hat man als Prozess immer den Vorteil, dass man den Adressraum exclusiv in voller Größe nutzen kann und niemand anderes den eigenen Speicher fragmentiert. Ob das in der Praxis ausreicht um im konkreten Fall den OoM zu verhindern ist natürlich ne andere Sache. Eine geringe Chance, dass der zusätzliche Speicher genau ausreicht besteht aber immer. In der Praxis ist der Fall das real und virtuell gleich groß ist auch sehr exotisch, da ein entscheidender Vorteil ja gerade ist, den Adressraum virtuell größer zu haben. Lediglich bei X86 auf dem privaten Desktop hatte man das in manchen Fällen, da sich 64-Bit Betriebssysteme dort zu langsam durchsetzten.--Trockennasenaffe (Diskussion) 16:49, 10. Jul. 2012 (CEST)
"Dieser [große Adressraum] ist aber in der Praxis praktisch immer gegeben." ~ Nja, sag das mal den Leuten mit 2-4 GB Ram und 'nem Win32 / Linux32 OS. --arilou (Diskussion) 17:53, 10. Jul. 2012 (CEST)
Sorry, war mal wieder schneller im Editieren als im Lesen - im letzten Satz sagst' ja dasselbe. --arilou (Diskussion) 17:55, 10. Jul. 2012 (CEST)

Um mal zum Ausgangsproblem zurück zu kommen:

"Eine weitere nützliche Eigenschaft des virtuellen Adressraums ist die Möglichkeit, Speicherfragmentierungen zu kaschieren, insbesondere wenn der virt. Adressraum deutlich größer ist als der physikalische Speicher."

Das müsste man eigentlich präzisieren auf

  1. den Fall, dass die Speicherfragm. durch gemeinsamen Adressraum mit anderen Anwendungen aufträte;
  2. den Fall, dass das Programm selbst so blöd ist, seinen Adressraum zu zerfransen.

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

zu 2.: jegliches nicht-triviales Programm welches Speicher verschiedener grösse allokiert und deallokiert fragmentiert seinen Speicherraum. Nur triviale Programme oder explizite dynamische Speicherverwaltung vermeidende Programme tun dies nicht.
zur Ursprungsfrage, gebe dir recht wir haben hier auch Kommunikations- bzw. Begrifflichkeitsproblem deswegen werde ich versuchen deutlicher und schärfer mit klaren Beispielen verschiedene Verhalten zu belegen. gruesse Shaddim (Diskussion) 12:14, 11. Jul. 2012 (CEST)

Situation 1: System nach neustart, unfragmentierte real-address-space (RAS) (wenig geladenen treiber, systemprogramme dienste etc.)

Zeitpunkt 0: 1: treiber, dienste, etc., 2: dynamische bibliotheken 

           0                                            4GB
RAS        |-----------------vvvvvvvvvvvvv----------------|
mapping                      |   1   |  2|

VAS        |----------------------------------------------|

Zeitpunkt 1: ohne virtuelle Speciherverwaltung Programm allokiert drei speicherbereiche 3,4,5 

           0                                            4GB
RAS        |vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv-----|
mapping     |3    |   4     ||   1   |  2|     5     |

erfolgreich

Zeitpunkt 1: mit virtueller Speciherverwaltung Programm, allokiert drei speicherbereiche 3,4,5 

           0                                            4GB
RAS        |vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv----|
mapping     |3    |   4     ||   1   |  2|      5    |

mapping     |5          | | 2  |   |  3  | 1 | |4       |
VAS        |vvvvvvvvvvvvv-vvvvvv---vvvvvvvvvvv-vvvvvvvvvv-|

erfolgreich
Situation 2: System nach einiger Laufzeit und Programmverwendung geladenen Treibe, dynamische Bibliotheken etc, fragmentierter real-address-space (RAS) (wenig geladenen treiber, systemprogramme dienste etc.)

Zeitpunkt 0: 1: treiber, dienste, etc., 2: dynamische bibliotheken 

           0                                            4GB
RAS        |---vv-------vvv-------vvvv--vvv--vv-----------|
mapping        |1       |1|       | 1|  |2|  |2


Zeitpunkt 1: ohne virtuelle Speicherverwaltung, Programm allokiert drei speicherbereiche 3,4,5 

          0                                            4GB
RAS        |---vvvvvvvvvvvv-------vvvv--vvv--vvvvvvvvvvvvv|
mapping        |1|  3   |1|       | 1|  |2|  |2|     4



allokierung von sequentiellem platz für anforderung 5 (13 blöcke) schlägt fehl, freie Blöcke 15, grösster freier block 8

Zeitpunkt 1: mit virtueller Speicherverwaltung, Programm allokiert drei speicherbereiche 3,4,5 

          0                                            4GB
RAS        |vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv-vvvvvvvvvvvvv|
mapping      5 |1|  3   |1|   5   | 1| 5|2|5||2|     4

mapping     |5          | | 2  |   |  3  | 1 | |4       |
VAS        |vvvvvvvvvvvvv-vvvvvv---vvvvvvvvvvv-vvvvvvvvvv-|

allokierung von 5 erfolgreich

d.h. auch bei gleicher Grösse bringt die virtuelle Speicherverwaltung einen Vorteil gegenüber der direkten unvirtualisierten. Es löst das Problem der des physikalischen Speicher Fragmentierung, eliminiert als einen Out-of-memory fall.

gruesse Shaddim (Diskussion) 18:18, 11. Jul. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: arilou (Diskussion) 14:41, 1. Jul. 2013 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Virtuelle_Speicherverwaltung/Archiv/1&oldid=225539942“