🚀 go-pugleaf

Andrey.Behrens@gmx.de <Andrey.Behrens@gmx.de> wrote:

>Nein. Die interne Speicherverwaltung des _anderen_ Unixes "sieht" 
>nur dann den RAM, wenn ausreichend Swap vorhanden ist. Keine Ahnung
>warum.

Diese Unixe verwalten den virtuellen Speicher wie es bei Caches gemacht
wird.

Wenn Speicher angefordert wird, dann wird der entsprechende Bereich in
der Swap-Partition belegt. Wenn dann ein Programm tats�chlich auf
diesen Speicher zugreifen will, dann wird die Seite ins RAM
eingelagert. Das hei�t, die Gr��e des virtuellen Speichers ist gleich
der Gr��e des Swap-Bereiches. Der Hauptspeicher dient lediglich als
Cache.

Genauso arbeiten die L1/L2-Caches. Adressiert wird der Hauptspeicher,
und erst wenn ein Programm auf eine Speicheradresse zugreift, wird sie
in den Prozessorcache eingelagert. Die Gr��e des Speichers ist
gleich der Gr��e des Hauptspeichers und nicht die Summe aus
Hauptspeicher und Caches.

Nun ist es beim typischen Linux-System (und wohl auch bei Windows) so,
da� meist nicht viel mehr virtueller Speicher verwendet wird als
Hauptspeicher vorhanden ist (wenn's hoch kommt Faktor 2-3). Im
Gegensatz dazu stehen beim Prozessor-Cache ein paar hundert kB Cache
mehreren MB Hauptspeicher gegen�ber (typisch: Faktor 64-1024). W�hrend
sich bei Linux also die komplexere Speicherverwaltung lohnt, bei der
sich Hauptspeicher und Swap addieren, w�rde das bei Prozessor-Caches
keinen nennenswerten Vorteil bringen (0,1% - 1%, wirklich l�cherlich).

Beim Swap so vorzugehen, wie bei Prozessor-Caches kann durchaus auch
Vorteile bringen. Da m�ssen die OS-Designer eben abw�gen.

Peter
-- 
  _   x    ___   p.steiner@t-online.de (Peter Steiner)
 / \_/_\_ /,--' Linux User #55148 (http://counter.li.org/)
 \/>'~~~~//
   \_____/ perl -e'while(<>){s/=\n//g;s/=([\dA-F]{2})/chr(hex($1))/eg;print;}'