symlink.ch
Wissen Vernetzt - deutsche News für die Welt
 
symlink.ch
FAQ
Mission
Über uns
Richtlinien

Moderation
Einstellungen
Story einsenden

Suchen & Index
Ruhmeshalle
Statistiken
Umfragen

Redaktion
Themen
Partner
Planet

XML | RDF | RSS
PDA | WAP | IRC
Symbar für Opera
Symbar für Mozilla

Freunde
Benutzergruppen
LUG Switzerland
LUG Vorarlberg
LUGen in DE
SIUG
CCCZH
Organisationen
Wilhelm Tux
FSF Europe
Events
LinuxDay Dornbirn
BBA Schweiz
CoSin in Bremgarten AG
VCFe in München
Menschen
maol
Flupp
Ventilator
dawn
gumbo
krümelmonster
XTaran
maradong
tuxedo

 
Speicherverwaltung für den L4 GNU Hurd
Veröffentlicht durch tuxedo am Donnerstag 20. Januar 2005, 17:11
Aus der a-hurd-of-GNUs Abteilung
Open Source Unser Leser benjamin weist uns auf einen Artikel bei Kerneltrap.org hin, wonach GNU Hurd-Entwickler Neal Walfield das Memory Management Framework für den Hurd L4 Port (nicht zu verwechseln mit dem Mach Hurd) committed hat. Im Unterschied zu anderen Kerneln, welche die Speicherverwaltung komplett im Kernelspace abwicklen (z.B. Linux oder der Mach Hurd), verwaltet der L4 Hurd den Speicher im Userspace. Dazu stellt er den Server physmem zur Verwaltung des physikalischen Speichers und die libhurd-mm, eine Userspace-Library welche zur Verwaltung des virtuellen Speichers eingesetzt wird zur Verfügung.

Dies ist insofern spannend, als dass die Applikationen, welche auf dem L4 GNU Hurd ausgeführt werden, ihren virtuellen Speicher selbst verwalten müssen, was eigentlich den Unix-Konzepten widerspricht. Dies führt aber dazu, dass der Kernel keine Annahmen über die Art der Prozesse (I/O-intensive, CPU-intensive) treffen muss, sondern dies von Prozess selbst übernommen wird. Multimedia-Anwendungen oder Datenbanken können von diesem Verhalten profitieren.

Spamhinweise werden ignoriert | Druckausgabe | HP führt Regionalcodes auf Tintenpatronen ein  >

 

 
symlink.ch Login
Login:

Passwort:

extrahierte Links
  • GNU
  • Linux
  • Was ist ein Wiki?
  • Wikipedia
  • Artikel bei Kerneltrap.org
  • GNU Hurd
  • Neal Walfield
  • L4
  • committed
  • virtuellen Speicher
  • Mehr zu Open Source
  • Auch von tuxedo
  • Diese Diskussion wurde archiviert. Es können keine neuen Kommentare abgegeben werden.
    Unix®-Konzepte und so (Score:1)
    Von mirabile (root@[IPv6:2001:6f8:94d:1:200:24ff:fec2:9ed4]) am Thursday 20. January 2005, 23:25 MEW (#1)
    (User #504 Info) http://mirbsd.de/
    L4 ist ja auch kein Unix® und erhebt nicht den
    Anspruch.

    Man kann allerdings Unix® auf dem L4 laufen lassen,
    und wir wurden schon gebeten, MirOS drauf zu por-
    tieren.

    Ich bin BSDler, ich darf das!
    06.03.2005 00:24 UTC
    #1 der Hall of Fame: 2⁷ Kommentare
    Virtuelle Speicher selber verwalten (Score:2)
    Von dino (neil@franklin.ch.remove) am Friday 21. January 2005, 10:48 MEW (#2)
    (User #32 Info) http://neil.franklin.ch/
    ihren virtuellen Speicher selbst verwalten müssen

    Ich nehm jetzt mal an, dass damit gemeint ist, dass sie ihre mmap() Adressspace->File Zuordnungen und page-ins selber machen muessen. Und vermutlich auch gleich allen File input per mmap() simulieren.

    Disk und File output wird dann zur Sache des page-out vom Kernel (alles RAM als Disk Cache), wobei dann die Frage auftaucht, wieweit die Prozesse steuern was wann rausgeschrieben wird und wann Speicher abgegeben wird, und ob der Kernel da irgendwie Zwang ausueben tut (z.B. Prozess benachteiligen), oder nur sich auf goodwill verlassen kann (unbrauchbar auf Multiuser Systemen).

    was eigentlich den Unix-Konzepten widerspricht

    Welchem Konzept soll da widersprochen werden? Moeglichst viel im User Space machen ist eigentlich in Unix erwuenscht. Die tun das nur etwas konsequenter umsetzen. Traditionelles Unix hat da den Sprung von Segmenten/swapping/PDP-11 zu PMMU/paging/VAX+spaetere immer noch nicht vollstaendig verdaut!

    Im verwiesenen Artikel steht auch nur "unterscheidet sich vom ueblichen Unix Modell".

    Dies führt aber dazu, dass der Kernel keine Annahmen über die Art der Prozesse (I/O-intensive, CPU-intensive) treffen muss

    Huh? Der Kernel muss immer noch entscheiden welcher Prozess die CPU bekommt, und dafuer wurd er das weiterhin bestimmen wollen, damit interaktive Programme (User wartet) gegenueber lang laufenden Berechnungen (User eher was anderes am machen) bevorzugt werden.

    Im verwiesenen Artikel wird auch nur davon gesprochen, dass der Kernel keine Disk Zugriffsmuster erraten muss, nix von IO vs CPU.

    sondern dies von Prozess selbst übernommen wird

    Das widerspricht aber krass der ganzen Idee von Prozessorzuordnung, wegen dem man ueberhaupt unterscheidet.

    Bei mmap() und Zugriffsmustern ist das dagegen einiges sinnvoller wenn das die Prozesse machen.

    Multimedia-Anwendungen oder Datenbanken können von diesem erhalten profitieren.

    Die duerften vor allem vom selbst gemachten optimierten mmap() profitieren.
    --
    hardware runs the world, software controls the hardware,
    code generates the software, have you coded today

    Linux User Group Schweiz
    Durchsuche symlink.ch:  

    Never be led astray onto the path of virtue.
    trash.net

    Anfang | Story einsenden | ältere Features | alte Umfragen | FAQ | Autoren | Einstellungen