Diskussion:Speicherverwaltung

Revert "Löschung 'Direkte Speicherverwaltung'"

Mir ist nicht klar, warum ein ganzer Abschnitt ersatzlos gestrichen wurde (Direkte Speicherverwaltung). Deshalb von mir ein Revert. --Friese 17:18, 7. Okt 2004 (CEST)

Die Verwaltung ist nicht nur Teil des Betriebssystems

Die Speicherverwaltung wird zu großen Teilen von Hardware wie z.B. MMU, Prozessor, Chipsatz übernommen. Das Betriebsystem initialisiert die Speicherverwaltungshardware, stellt Dinge Segmentgrößen ein und übernimmt die Ein- und Auslagerung von Speicherseiten. Die "Drecksarbeit", wie z.B. bei jedem Speicherzugriff zu prüfen ob er im erlaubten Segment liegt, übernimmt aber die Hardware.

Anfangs

Bis zu welcher Version? Bis 3.11? --SonniWP2 06:29, 31. Jul. 2007 (CEST)

Segmentierung

• "Diese Art der Speicherverwaltung war in den Anfängen der Entwicklung von Computern weit verbreitet."

So weit ok.

• "Das Betriebssystem MS-DOS nutzte anfangs ausschließlich die Segmentierung."

Jein, für das auszuführende Programm werden sog. Segmentregister gesetzt; da wurde aber niemals etwas "ausgelagert" o.ä., es war mehr ein Weg, 20-Bit Adressraum mit 16-Bit-Registern zu verwenden.

Der Kernaapekt an Segmentierung ist nicht die Auslagerung (das ist eine Anwendungsmöglichkeit) der Kernaspekt ist die fehlende Möglcihkeit der zugreifbarkeit parallel auf alle Speciherbereiche sondern immer nur innerhalb auf eines Bereich frei und unlimitiert (64kB), innerhalb eines Segments. Um auf andere Bereich (die restlichen 640kb-64kb) zuzugreifen muss etwas umgeschaltet werden (eine Limitierung der freien Zugreifbarkeit, man kann also zB kein überlappendes memcopy aus bereich 1 in bereich 2 machen), ein Segment-Register. Also ein klares JA bei DOS bzw dem real mode. (Wenn man noch XMS und EMS hinzunimmt ein weiteres JA). Shaddim (Diskussion) 19:03, 11. Jul. 2012 (CEST)

Da es für eine Anwendung nicht das geringste Hindernis gibt, in CS/DS/ES/SS einfach einen anderen Wert zu schreiben, neige ich stark dazu, das nicht als "Speicherverwaltung mit Segmentierung" aufzufassen, sondern einfach als einen verkorksten Weg, 20 Bit Adressraum mit 16 Bit Registern anzusprechen. Dass mache Maschineninstruktion auch nur 16-Bit-fähig ist, ist bei einem 16-Bit-Chip jetzt nicht soooo verwunderlich.

Wenn zu mir jemand etwas von "Segmentierung bei x86-Chips" sagt, denke ich nur an PAE; die Register CS/DS/ES/SS haben einfach so wenig mit Segmentierter Speicherverwaltung zu tun, dass es ein Witz ist, das hier einzuordnen.

Nenn' mir bitte eine andere Möglichkeit, einen 16-Bit-Prozessor mehr als 2^16 Byte Ram adressieren zu lassen (mit 16-Bit-Registern), als irgendwie 2 Register zu kombinieren à la xxxx:yyyy . Es gibt Legionen an 8-Bit-Microkontrollern, die genau so 64k Ram ansprechen, und niemand kommt auf die Idee, diesen eine "Speicherverwaltung mit Segmentierung" anzudichten.

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

hmm, ich glaueb ich verstehe deinen Segmentierungbegriff nicht ganz, meinem Verständnis nach ist genau dies die Essenz von Segmentierung. feste (hier 16bit grosse) bereiche (Segmente) die frei zugreifbar sind, grössere nur über hässliche Erweiterungsmechanismen mit einschränkungen (z.B. memcopy oder allokierung). Shaddim (Diskussion) 11:36, 12. Jul. 2012 (CEST)

Es gab in MS-DOS auch nicht "mehrere aktive Prozesse", allenfalls kann man damit Treibern u.ä. ermöglichen, "ihren Adressraum" (ihr 64k-Segment) "lokal" zu adressieren.

TSR-Programm (pseudo-parallel)

Das meinte ich mit "Treiber u.ä.". --arilou (Diskussion) 10:35, 12. Jul. 2012 (CEST)

Ab dem 80386 hat "Segmentierung" bzgl. Arbeitsspeicher aber eine andere Bedeutung, und wird nur von einer Handvoll Win32-Server-Versionen tatsächlich für einen größeren Adressraum verwendet (siehe Physical Address Extension), allen anderen geht's nur um das NX-Bit.

Extended Memory Specification und XMS, ebenfalls segment basierend. Shaddim (Diskussion) 19:03, 11. Jul. 2012 (CEST)

Hab' mir das mal angeschaut, v.a. Unreal mode, da wird auch nicht sauber getrennt zwischen "CS/DS/ES/SS"-Registern (deren 32-Bit-Versionen), und der PAE. Was du jetzt mit "segment basierend" meinst, ist mir daher ebenfalls unklar. --arilou (Diskussion) 10:35, 12. Jul. 2012 (CEST)

nein ich meine bei XMS und EMS wird speicher jenseits 1MB wird über Fenster segmentweise in den 1MB bereich eingeblendet, eine Segmentierung. gruesse Shaddim (Diskussion) 11:36, 12. Jul. 2012 (CEST)

• "Bei heutigen Prozessoren wird im Allgemeinen die Segmentierung mit der Seitenadressierung kombiniert und wird dann als Paging bezeichnet."

Wie zuvor: PAE wird von heutigen (64Bit-)Betriebssystemen nur noch für das NX-Bit verwendet, mit der Speicherverwaltung, welcher Prozess welche Pages bekommt, hat das ganze eigentlich nichts mehr zu tun. Auf jeden Fall wird nicht "für jeden Prozess ein PAE-Segment" verwendet, wie man es aus dem Artikel verstehen könnte.

--arilou (Diskussion) 13:59, 11. Jul. 2012 (CEST)

Der Abschnitt scheint mir generell zu Desktop und x86 zentriert. Meines Wissens nach war Segmentierung nur bei x86 und Microsoft verbreitet. Bei MS-DOS wurde die Segmentierung für den Speicherschutz und zur Vereinfachung der Speicherverwaltung und teilweise zur Vergrößerung des nutzbaren Speichers verwendet. Es ist möglich, aber nicht notwendig, Paging mit Segmentierung zu kombinieren. Viele Prozessorfamilien können überhaupt keine Segmentierung. Bei Linux wurde auch auf x86 nie klassische Segmentierung verwendet sondern nur Paging. Das NX-Bit hat nichts mit Segmentierung zu tun sondern dient gerade dazu auf x86 auch bei reinem Paging einen Speicherschutz zu realisieren. Damit viel der letzte Vorteil der klassischen Segmentierung weg.--Trockennasenaffe (Diskussion) 14:47, 11. Jul. 2012 (CEST)

1. "[...] war Segmentierung nur bei x86 und Microsoft verbreitet" - mitnichten. Segmentierung war weit verbreitet bei Großrechnern, schon lange vor Microsoft. (Man muss dabei ziemlich aufpassen, dass man nicht die x86-"Segmentregister" mit der 80386ff-PAE-Segmentierung des Ram vermischt. Die frühen Großrechner waren da durchaus mit zweiterem und entsprechenden MMUs ausgestattet.)

Ob der heutige Betrieb von virtuellen Maschinen auf einem Host auch als "Segmentieren" gilt, wenn man den virt.Maschinen jeweils eine feste Ram-Größe zuordnet, weis ich nicht.

2. "Bei MS-DOS wurde die Segmentierung für den Speicherschutz und zur Vereinfachung der Speicherverwaltung und teilweise zur Vergrößerung des nutzbaren Speichers verwendet."

• MS-DOS kennt keinen Speicherschutz. Ist bei Singletasking auch nicht wirklich relevant.
• Eine "Vereinfachung der Speicherverwaltung", hm, möglich. So genau kenn' ich MS-DOS' Speicherverwaltungs-Algorithmen nicht, aber eine Vereinfachung bezweifel ich eher.
• "Vergrößerung des nutzbaren Speichers" - da hätt' ich gerne eine Erklärung, was damit gemeint sein soll.

Es gab (EMM386.exe, HiMem.sys) DOS-Hilfen, um bei 286/386ern das Ram über 1MB anzusprechen. Und da mehrere "Programme" (RamDrive.sys, SmartDrv.exe, Anwendungsprog.) "gleichzeitig" Teile davon ansprechen konnten, muss es auch eine gewisse Verwaltung davon gegeben haben, ja. Ob dabei die Segmentierungsfähigkeiten des 386-Prozessors (PAE) eingesetzt wurden, müsst' man mir erst belegen, bevor ich das glaube. (In Unreal mode wird nicht sauber getrennt, es ist unklar, ob dabei nur mit (32-Bit) CS/DS/ES/SS gearbeitet wird, oder Einstellungen von PAE gesetzt werden.)

PAE wurde erst am Ende der DOS-ära als Hardwaremöglichkeit eingeführt, bei Pentium Pro, d.h. aus abwärtskompatiblitätsgründen wurde es vermieden zu verwenden. PAE war deswegen auch später in der Praxis auch selten bis nie im Einsatz auch am Ende der 32bit Ära wo es drängend wurde, die meistens setzten dann gleich auf 64bit. Shaddim (Diskussion) 11:44, 12. Jul. 2012 (CEST)

3. "Das NX-Bit hat nichts mit Segmentierung zu tun" - Jein. Man muss auf Intel-/AMD-Chips PAE einschalten (auch wenn man dann das ganze Ram nur als 1 großes Segment angibt, also die Segmentierung eigentlich nicht verwendet), um die NX-Bit-Behandlung mit einzuschalten.

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

Irgendwie verstehe ich das nicht. PAE gibt es ab Intel Pentium Pro und ist eine Erweiterung der Paging-Einheit, die es erlaubt durch eine veränderte Hierarchie von Seitentabellen mehr Speicher zu adressieren. Es stimmt auch, das man oft erst damit das das NX-bit bei einem Tabelleneintrag setzen kann. Aber was hat das mit Segmentierung zu tun? Unter Segmentierung verstehe ich, dass man spezielle Segmentregister hat mit deren Hilfe man den Speicher in Segmente einteilt denen gewisse Atribute zugeordnet werden und man dadurch den Speicher Segmentrelativ adressieren kann. Diese Segmentregister verwendet aber heute praktisch niemand mehr und bei ARM PowerPC und vielen anderen gibt es sie überhaupt nicht.--Trockennasenaffe (Diskussion) 10:49, 12. Jul. 2012 (CEST)

Strategien

Eigentlich sollte man/ich den Abschnitt Virtuelle Speicherverwaltung#Platzierungsstrategien von Betriebssystemen hierher, in diesen Artikel hier, verschieben. Geht ja schließlich um allgemeine Strategien, die nicht von "virtuell" abhängig sind (z.B. beim alten Amiga gab's Multitasking, aber keinen Speicherschutz/virtuellen Adressraum. Da muss das OS auch "strategieren", ganz ohne "virtuell".) --arilou (Diskussion) 14:11, 11. Jul. 2012 (CEST)

finde ich eine gute Idee. gruesseShaddim (Diskussion) 19:05, 11. Jul. 2012 (CEST)

Grösse der Page-Frames

Im Abschnitt Paging heisst es neuerdings

In realen Systemen kommen Seitengrössen zwischen 512 Byte[18] und 1 GB vor.

Seintengrössen von 1 GB bedeuten eine enorme interne Fragmentierung. Das ist doch kaum realistisch ?! In der ursprünglich zitierten Quelle (Tanenbaum, 2009, S. 243) heisst es übrigens: In realen Systemen kommen Seitengrössen zwischen 512 Byte und 64 KB vor. Das mag nicht mehr ganz so aktuell sein, aber immer noch realistisch.

Zum Verweis auf die IA32-Architektur: Diese stellt eine standardmässige Seitengrösse von 4 KB zur Verfügung. (Siehe z.B. Klaus Wüst, Mikroprozessortechnik, 4. Aufl., 2011, S. 195ff.) Bei einer maximalen Grösse von 4 GB kann dabei ein Segment in 1048576 Seiten aufgeteilt werden. Wollte man diese Seiten mit einer einzigen Seitentabelle verwalten, hätte diese eine Grösse von 4 MB (4 Byte x 1048676). Bei PCs mit weniger als 4 MB physikalischem Arbeitsspeicher hätte man damit noch nicht einmal die Seitenverwaltungstabelle laden können. Deshalb entschied sich Intel für eine zweistufige Seitenverwaltung, bei der ein zentrales Seitenverzeichnis (page directory) auf bis zu 1024 Seitentabellen (page tables) verweist. Dadurch braucht man nicht mehr Seitentabellen als nötig anzulegen und die Seitentabellen selbst können ebenfalls ausgelagert werden...

Ich werde deshalb die zitierte Aussage wieder rückgängig machen. --Didia (Diskussion) 17:22, 20. Okt. 2016 (CEST)

Dann ist Tanenbaum eben noch veralteter, als ich dachte.

Page-Tables bei x64-Prozessoren sind mittlerweile bis zu vierstufig, wenn man 4-kB-Pages wünscht. Da das ein ziemlicher Verwaltungs-Wahnsinn wird und die MMU für eine Adressumsetzung dann auch bis zu 4* aus dem Ram nachladen muss, kennen x64-MMUs auch andere Betriebsmodi, die 3- oder nur 2-stufig sind. Dann werden die Pages aber größer als 4 kB.

Bei Windows XP konnte man einstellen, ob 4-kB-Pages oder 2-MB-Pages verwendet werden sollten. Nachfolgende x64-Windows-Versionen (also ab Vista) verwenden nur noch 2-MB- oder größere Pages, afaik kann man sie nicht mehr auf 4-kB zurückstellen.

"Maximale Ram-Größe von 4 GB" ~ in welcher Welt lebst du? Schon ein Smartphone hat heute 4 GB Ram, der PC hier vor mir hat 32 GB, die Workstation im Büro hat 768 GB. Den letzten PC mit nur 4 MB Ram hatte ich in den frühen 1990ern. DOS mit Ram-Disk.

Beleg für 1GB-Pages siehe Artikel Paging#Reales Beispiel: IA32-Architektur, Abschnitt 64-Bit-Modus.

Das veraltete Tanenbaum-Zitat reverte ich.Unnötig, die 4-MB-Pages nennst du ja inzwischen.

--arilou (Diskussion) 09:58, 21. Okt. 2016 (CEST)

Dann bitte ich dich, die entsprechenden Aussagen mit Belegen zu untermauern. Fragt sich, in welcher Welt du lebst, wenn du von Seitengrössen von 1GB sprichst. Auf meinem Linux-System mit x64 Architektur werden übrigens durchaus noch Seitengrössen von 4 KB verwendet. Das lässt sich einfach mit dem Befehl getconf PAGESIZE herausfinden. Das Beispiel mit der IA32-Architektur hast übrigens du gebracht, also bitte... Bitte halte dich mit unqualifizierten und unbelegten Änderungen zurück, ich werde diese einfach rückgängig machen... --Didia (Diskussion) 10:34, 21. Okt. 2016 (CEST)

Die 1 GB sind jetzt belegt, direkt durch AMD. --arilou (Diskussion) 12:03, 21. Okt. 2016 (CEST)

So ist es schon besser, danke. --Didia (Diskussion) 12:34, 21. Okt. 2016 (CEST)

Noch ein Nachtrag zu den Seitengrössen unter Windows (nach Mandl, Grundkurs Betriebssysteme, 2014, S. 251-252): Bei x86-Architekturen ist die Adressierung zweistufig, bei x64-Windows sogar vierstufig. Es werden auch sogenannte Large Pages zur Minimierung der Seitentabellen unterstützt. Allerdings muss für die Nutzung von Large Pages genügend Hauptspeicher verfügbar sein. Seitengrössen unter Windows in Abhängigkeit der Prozessorarchitektur nach Mandl und Tanenbaum:

Prozessorarchitektur	Grösse der Small Page	Grösse der Large Page
X86	4 KB	4 MB
x64 (AMD)	4 KB	2 MB
IA64 (Intel)	8 KB	16 MB

--Didia (Diskussion) 11:31, 21. Okt. 2016 (CEST)