Diskussion:Memory Management Unit

Grafiken

Ich habe mir mal die Mühe gemacht, darzustellen, wie eine x86-kompatible CPU mit und ohne PAE lineare Adressen in physische Adressen umwandelt. Im 32-Bit-Protected Mode kann das auf 4 verschiedene Arten geschehen. Diese kann man nun in den Text einbauen und erläutern.

• 
• 
• 
• 

--RokerHRO 12:53, 20. Mär. 2008 (CET)

virtuelle MMUs

Könnte vielleicht auch erwähnung finden. Nested Pages bei AMD genannt. (nicht signierter Beitrag von Laderio (Diskussion | Beiträge) 16:34, 21. Mär. 2009 (CET))

Kontext

woher weiß die MMU denn, welches programm / welcher virtuelle speicherraum gerade aktuell/gültig ist? Das OS muss doch irgendwie einen geschützten/autorisierten zugriff auf die MMU haben, um der MMU mitzuteilen, welches programm jetzt läuft. Der Artikel ist da unaussagekräftig. --Moritzgedig 11:28, 4. Mai 2011 (CEST)

Das schreibt das Betriebssystem während eines Kontextwechsels (-> Scheduling) in die MMU, wobei die MMU selbsttätig zwischen User- und Systemzugriffen unterscheiden kann. Bevor die MMU initialisiert wurde liefert sie eine 1:1 Umsetzung. Das BS muß halt bevor die MMU eingeschaltet wird passende Mappings aufsetzen, so daß das BS danach noch an die Register der MMU herankommt. Sun Hardware (MC-680x0 und Sparc) hat zusätzlich einen MMU-Bypass um bei defekter MMU eine Fehlermeldung auf der seriellen Schnittstelle ausgeben zu können. --Schily 14:29, 4. Mai 2011 (CEST)

"wobei die MMU selbsttätig zwischen User- und Systemzugriffen unterscheiden kann" Wie denn? --Moritzgedig 08:09, 8. Mai 2011 (CEST)

Das Minimum was eine passende CPU können muß ist ein extra Draht der dazwischen unterscheidet und der in die MMU führt. --Schily 14:51, 8. Mai 2011 (CEST)

Ah, macht sinn, nur, dass ich das für unselbstständig halte. Der Artikel sollte das explizit sagen, sonst ist es unverständlich. --Moritzgedig 09:16, 10. Mai 2011 (CEST)

Architektur

Der Aktuelle Artikel scheint nach meiner Kenntniss nur auf die Intel/i86 Architektur zu passen - ohne das dies jedoch erwähnung findet. Unterschiede zw. dieser und anderen CPU-Architekturen sollten dargestellt werden oder; wenn es jemand weiß; hinzugefügt werden das dies Allgemeiner Gültig ist. Auch sollte wohl klargestellt werden das erst neuere i86 CPUs eine "richtige" MMU beinhalten, davor gab es diese m.E. nur in Teilen die auf der Weiterentwicklung basierten vom 80286/386 mit Protected Mode, Deskriptoren (Adressumrechnungen) u.s.w. inkl. Paging (Virtuelle Adressen). -- 84.144.198.2 05:37, 6. Mai 2011 (CEST)

Ich sehe nicht, was am aktuellen Artikel x86-spezifisch sein soll. Außer dass die "translation lookaside buffer" auf anderen Architekturen anders heißen mögen, aber etwas Vergleichbares gibts dort auch. --RokerHRO 09:54, 6. Mai 2011 (CEST)

Gut, das kann ich nicht beurteilen da ich keine anderen Architekturen kenne ausser i86 (ich schrieb ja, meiner Kenntniss nach). Aber ist so eine Anmerkung nicht sinnvoll - zumal diese Architektur so weit verbreitet ist. Oder wird das allg. als unausgesprochene annahme gesehen? In dem Fall wäre ein Hinweis auf Architektur-unterschiede m.E. trotzdem hilfreich. Oder? -- 84.144.166.102 15:47, 6. Mai 2011 (CEST)

Wie ich schon schrieb: Ich finde keine architekturspezifischen Angaben im Artikel, außer dem Begriff "Translation lookaside buffer". --RokerHRO 08:41, 7. Mai 2011 (CEST)

Der Artikel enthält eigentlich sowenige Informationen über die Arbeitsweise einer MMU, daß mit Ausnahme des TLB vermutlich keine Architekturspezifischen Informationen vorhanden sind. Ansonsten gibt es schon große Unterschiede jenachdem wie genau man hinsieht. MMUs gibt es mit Ausnahme der Cyber 9000 eigentlich auf allen auch historischen Plattformen die Multi-User-fähig waren.

Aber die alten MMUs waren meines Wissens nach alle für segmentierte Betriebssysteme konzipiert. Auch die 68451 (für den 68010) hatte nur 96 PTEs. Weil die alle vom BS ständig PTEs nachgeladen bekamen war es mit einer virtiellen Speicherverwaltung langsam wenn die Prozesse groß wurden. Deshalb haben die E-Techniker der Uni Berkeley eine simple MMU entworfen die man wenigsten schnell nachladen konnte und die mehr PTEs hatte (4096) und diese in ihre VAX mit BSD-UNIX eingebaut. Dieses Konzept wollten wir Programmierer auch bei den Rechnern der H.Berthold AG einführen aber die Hardwareabteilung wollte das nicht. Durch den Kauf von Sun Systemen haben wir dieses Prinzip dann als Sun MMU wiederbekommen. Diese simple MMU ist aber bei ca. 64 MB RAM am Ende, weil das BS sonst einen wichtigen Anteil der Zeit mit dem Nachladen der PTEs beschäftigt ist. Daher kamen gegen Ende der 1980er die ersten selbstnachladenden MMUs. Die haben dann TLBs.

Sobald man aber die Stufenzahl der MMU (1..3-stufig - oder gar mehr) und selbstladende MMUs so beschreiben würde, daß die Funktion auch verstanden werden kann, wird es immer plattformspezifisch. --Schily 16:35, 7. Mai 2011 (CEST)

Der wichtigste Bestandteil der MMU fehlt im Artikel

Der wichtigste Teil der MMU sind die Page Table Entries, die weder im Artikeltext noch im Schaubild Erwähnung finden. Der Artikel kann daher nur als rudimentäre Basisinformation gesehen werden. Der englische Artikel ist zwar auch nicht optimal aber merklich besser als der deutsche. --Schily 17:42, 10. Mai 2011 (CEST)

Memory Protection Unit

Ich habe mal auf einer ARM-CPU gearbeitet die nur eine MPU, keine MMU hatte. Kann man eine MPU als "Vorläufer" einer MMU bezeichnen? Zumindest sollte aber die MPU im Artikel erwähnt werden. Enthält nicht jede moderne MMU auch die MPU-Funktionalität? --188.104.119.140 09:03, 11. Mai 2011 (CEST)

Performance

Ich kann mir vorstellen, dass die Übersetzung zwischen logischer und physischer Adresse in der MMU eine gewisse Zeit in Anspruch nimmt. Würde die CPU direkt den Arbeitsspeicher adressieren, könnte das System schneller rechnen, auch wenn dafür mit einem Verlust an Sicherheit bezahlt werden müsste. -- Indoor-Fanatiker 06:31, 24. Aug. 2011 (CEST)

Die Geschwindigkeitssteigerung durch Deaktivierung der MMU wäre unwesentlich, da die MMU ja parallel zum CPU-Kern arbeitet. Die von der MMU benötigten Übersetzungstabellen (page tables) werden ebenfalls innerhalb der MMU gecachet, so dass auf sie ebenfalls flott zugegriffen werden kann. Nur wenn ein Programm fortwährend seinen Adressraum durchiteriert, so dass die Page Table Caches ständig neu geladen werden müssen, wird es langsam. Doch da Hauptspeicherzugriffe eh um den Faktor 10 bis 100 langsamer sind, als Zugriffe auf den CPU-internen Cache, spielt es da dann auch keine Rolle mehr, wenn nach 4096 langsamen Speicherzugriffen noch ein weiterer Speicherzugriff für das Laden eines neuen Page-Table-Eintrages notwendig wird. --RokerHRO 10:20, 24. Aug. 2011 (CEST)

Das ist korrekt. Bei echtzeitkritischen Anwendungen bevorzugt man daher immer noch CPUs die komplett ohne Paging und MMU auskommen. Denn bei letzteren beiden Dingen kann die Latenz ein störender Faktor sein. --IT-Compiler (Diskussion) 00:16, 15. Sep. 2022 (CEST)

Auslagern von z. Z. nicht benötigtem Speicher

Soll das nicht "Auslagern von z. Z. nicht benötigten Code und Daten" heißen? --IT-Compiler (Diskussion) 00:00, 15. Sep. 2022 (CEST)