> Speicherverwaltung für den L4 GNU Hurd > [http://www.symlink.ch/article.pl?sid=05/01/20/168205&mode=thread] > Open Source | Veröffentlicht durch tuxedo am 2005-01-20 16:11:11 > Aus der a-hurd-of-GNUs Abteilung > 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. ###### Virtuelle Speicher selber verwalten [http://www.symlink.ch/comments.pl?sid=05/01/20/168205&cid=2] (Score:2) von dino (neil@franklin.ch.remove) am Fri. 21. January 05, 10:48 MEW (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.