AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Tutorials [Artikel] Physischer Speicher und die Auslagerungsdatei
Tutorial durchsuchen
Ansicht
Themen-Optionen

[Artikel] Physischer Speicher und die Auslagerungsdatei

Ein Tutorial von Luckie · begonnen am 12. Mär 2006 · letzter Beitrag vom 14. Mai 2006
Antwort Antwort
Benutzerbild von Luckie
Luckie
Registriert seit: 29. Mai 2002
Und Supi-Luckie schlägt noch mal zu an diesem Wochenende. (Ich muss sagen, dieses Wochenende war ich sehr produktiv. )

Dies mal geht es darum, wie unter Windows der Arbeitsspeicher und die Auslagerungsdatei zusammenspielen:

Physischer Speicher und die Auslagerungsdatei unter Windows

Anlass war der Thread von Valle Arbeitsspeicher leeren und warum es nicht sinnvoll ist gewaltsam Windows dazu zu veralassen Arbeitsspeicher in die Auslagerungsdatei auszulagern.

Edit: Fehler im Diagramm behoben.
Ein Teil meines Codes würde euch verunsichern.
 
Olli
 
#2
  Alt 14. Mai 2006, 14:02
Einige Bemerkungen:

so scheint für die Anwendung jedoch insgesamz 164 MB Speicher zur Verfügung zu stehen
Für jede Anwendung stehen 4GB zur Verfügung, wobei unter Standardbedingungen 2GB davon Kernelspace sind (läßt sich konfigurieren). Der Kernelspace ist no-go. Also kann eine Anwendung davon ausgehen, daß sie 2GB zur eigenen Verfügung hat - was es schon verdeutlicht. Selbst heutzutage haben wenige Leute insgesamt 4GB in ihrem Rechner.

Für die Verwaltung dieses virtuellen Speichers ist natürlich eine erhebliche Unterstützung der CPU erforderlich.
Nope, das bringen die Prozessoren mit. Deswegen wurde ja der Protected Mode eingeführt. Das hin- und herscheffeln zwischen Dateisystem und RAM ist zwar u.U. CPU-intensiv, die Verwaltung an sich aber weniger.

Es dürfte klar sein, dass je öfter das Betriebsystem diesen Vorgang wiederholen muss, desto langsamer wird es.
Deswegen ist NT ja auch defensiv beim schreiben in die Auslagerungsdatei - nur wenig benutzte Seiten werden überhaupt ausgelagert. Man muß den Speicher schon stark einschränken, damit sich das negativ bemerkbar macht, deswegen gibt es Mindestanforderungen.

Insgesamt kann man aber Windows sowieso so leicht zu nichts zwingen - auch nicht zum Auslagern. Dazu reicht es beispielsweise nicht Speicher zu allozieren, sondern man müßte bspw. bei 512 MB RAM mal 450 MB allozieren und dann in einer engen Schleife immer wieder in diesen 450 MB zufällig rumkritzeln. Dann werden vermutlich andere Programme oder sogar Teile des OS ausgelagert, weil die Seiten in den 450 MB häufig benutzt werden.


Fipptehler:
transparatente -> transparente
insgesamz -> insgesamt
Arbeitsspecher -> Arbeitsspeicher
aktualiisert -> aktualisiert

(nur beim Überfliegen bemerkt - könnten also noch mehr sein )
  Mit Zitat antworten Zitat
Benutzerbild von idontwantaname
idontwantaname

 
Turbo Delphi für Win32
 
#3
  Alt 14. Mai 2006, 14:15
Ist da nicht ein Fehler im Diagramm ?? Da gehört meiner Meinung nach noch ein Pfeilchen hin.
(siehe Anhang)

mfg idontwantaname
Miniaturansicht angehängter Grafiken
memory_pagefile_183.jpg  
Oliver Hanappi
  Mit Zitat antworten Zitat
Frickeldrecktuxer_TM
 
#4
  Alt 14. Mai 2006, 14:26
Zitat von Olli:
Für die Verwaltung dieses virtuellen Speichers ist natürlich eine erhebliche Unterstützung der CPU erforderlich.
Nope, das bringen die Prozessoren mit. Deswegen wurde ja der Protected Mode eingeführt. Das hin- und herscheffeln zwischen Dateisystem und RAM ist zwar u.U. CPU-intensiv, die Verwaltung an sich aber weniger.
Ich nehme stark an, daß mit CPU nicht das bisschen gemeint war, das rechnet, sondern das komische Si-Substrat auf Keramikträger, das du in so ein rechteckiges Ding auf deinem Mutterbrett steckst
Es ist also erforderlich, daß die Adressierungseinheit PageFaults emittiert, also "paging-aware" ist, und diese Unterstützung muss der Prozessor mitbringen.

@idontwantaname: Jein. Wenn eine Seite ausgelagert werden muss, die nicht in der Auslagerungsdatei existiert, ist es egal, ob die Seite verändert wurde oder nicht. Selbst wenn sie nicht verändert wurde, muss sie in die Auslagerungsdatei geschrieben werden, sonst ist sie womöglich verloren. Das geht beim Rekonstruieren von Prozessen noch relativ einfach, indem man das Image neu einliest und relokiert, aber warum den Aufwand bei knappem Speicher bei nahezu jedem Task-Wechsel nochmal betreiben? Außerdem müsste zu jeder Page auch noch der Ursprung gespeichert werden.
  Mit Zitat antworten Zitat
Olli
 
#5
  Alt 14. Mai 2006, 14:35
Zitat von Frickeldrecktuxer_TM:
Ich nehme stark an, daß mit CPU nicht das bisschen gemeint war, das rechnet, sondern das komische Si-Substrat auf Keramikträger, das du in so ein rechteckiges Ding auf deinem Mutterbrett steckst
Es ist also erforderlich, daß die Adressierungseinheit PageFaults emittiert, also "paging-aware" ist, und diese Unterstützung muss der Prozessor mitbringen.
Schon klar. Das strengt die CPU aber nicht wirklich an. Das ist es was ich meinte. Das Kopieren (RAM <-> Pagefile) strengt die CPU mindestens ein bißchen an, die Page-Faults selber eher nicht.

Und aus Softwaresicht reden wir ja auch meist von der CPU als Recheneinheit und nicht als Si-Substrat auf Keramikträger
  Mit Zitat antworten Zitat
Frickeldrecktuxer_TM
 
#6
  Alt 14. Mai 2006, 14:48
Zitat von Olli:
Schon klar. Das strengt die CPU aber nicht wirklich an.
Wie gesagt ich denke nicht, daß tatsächlich nur die CPU (die Arithmetikwerke) gemeint war und somit mit "Unterstützung" auch nicht "Rechnerei". Der Prozessor muss massiv mithelfen, nämlich durch eine passende Adressierungseinheit, die nicht einfach die Adresse auf die Adressleitungen legt, egal ob am anderen Ende jetzt ein SDRAM hängt oder nicht.
Ansonsten kriegst du in $LADEN aber auch immer einen gesamten Prozessor mitsamt Caches und Keamikträger, wenn du eine CPU verlangst.

Zitat von Olli:
Das Kopieren (RAM <-> Pagefile) strengt die CPU mindestens ein bißchen an
Jupp, 'n bisschen, bis der DMA-Controller programmiert ist der dann das Kopieren übernimmt
  Mit Zitat antworten Zitat
Olli
 
#7
  Alt 14. Mai 2006, 15:18
Ich versuche es nochmal. Mir scheint es liegt an meiner Lesart.
Zitat von Frickeldrecktuxer_TM:
Wie gesagt ich denke nicht, daß tatsächlich nur die CPU (die Arithmetikwerke) gemeint war und somit mit "Unterstützung" auch nicht "Rechnerei". Der Prozessor muss massiv mithelfen, nämlich durch eine passende Adressierungseinheit, die nicht einfach die Adresse auf die Adressleitungen legt, egal ob am anderen Ende jetzt ein SDRAM hängt oder nicht.
Ansonsten kriegst du in $LADEN aber auch immer einen gesamten Prozessor mitsamt Caches und Keamikträger, wenn du eine CPU verlangst.
Ist ja richtig. Aber wenn ich das so lese wie es Luckie schreibt, entsteht bei mir der Eindruck, daß das OS nochmal überproportional extra Rechenzeit braucht um Page Fault Handling hinzubekommen. Braucht es ja auch (denn der PF Handler ist ja Code der ausgeführt werden muß), aber eben nicht überproportional. Im Gegenteil, es ist popelig wenig Rechenzeit verglichen mit dem Kopieraufwand.
  Mit Zitat antworten Zitat
Frickeldrecktuxer_TM
 
#8
  Alt 14. Mai 2006, 15:23
Zitat von Olli:
Aber wenn ich das so lese wie es Luckie schreibt, entsteht bei mir der Eindruck, daß das OS nochmal überproportional extra Rechenzeit braucht um Page Fault Handling hinzubekommen.
Dieser Eindruck entsteht bei mir nicht
  Mit Zitat antworten Zitat
Olli
 
#9
  Alt 14. Mai 2006, 15:31
Zitat von Frickeldrecktuxer_TM:
Zitat von Olli:
Aber wenn ich das so lese wie es Luckie schreibt, entsteht bei mir der Eindruck, daß das OS nochmal überproportional extra Rechenzeit braucht um Page Fault Handling hinzubekommen.
Dieser Eindruck entsteht bei mir nicht
Okay, Asche auf mein Haupt.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz