08.02.2014
(05.02.2014)404compliant schrieb: [ -> ]1Gb sind zu wenig, da brauchen wir nicht drüber reden. Aber ich sitze gerade an meinem 2Gb-Notebook. Uptime gerade 17 Tage, 400Mb freier Speicher, 100Mb Disk Cache, 400Mb unnötiger Kram im Swap, 3.8Gb Swap leer. Größter Einzelprozess ist Firefox mit 300Mb.
Man muß halt etwas Geduld haben.
Mein mac mini mit debian kommt auch mit 1GB RAM aus. Er hat aber keine Desktop-Workloads, die bei mir üblicherweise im Bereich 4 bis 6GB liegen und auch 8GB schon überschritten haben. Daher eben meine empfehlung, 16GB zu verbauen. 2x 8GB UDIMMs kosten nicht die Welt. Zum Vergleich, die letzten Mühlen die ich nem Kunden vorbeigebracht habe, hatten 384GB RAM, und das waren so kleine putzige Dinger zum reinschieben.
Zitat:... wovon die oberen 2Gb fürs Betriebssystem reserviert sind. Bei speziell übersetzten Programmen kann ein einzelnes Programm bis 3Gb nutzen, dazu muss aber auch die Windows-Konfiguration per Bootparameter umgestellt werden, damit sich Win32 auf 1Gb beschränkt. Hat aber manchmal den Nachteil, dass Grafikkarten ihren Framebuffer nicht mehr komplett in den Adressraum einblenden können, was zu seltsamen Fehlern führen kann.
Grundsätzlich ist da erstmal gar nichts reserviert. Ein 32bit Programm bekommt vom Kernel 2^32bit, also 4GB virtuellen Adressraum zugeteilt, pro Prozess. Unabhängig vom RAM, d.h. potenzieller Swapspace ist ggf auch enthalten. Der Kernel selber mapped da erstmal gar nichts rein, er verwendet auch einen komplett anderen Adressbereich.
Bei x86 gibts sogar noch die Ausnahme, daß seit Mitte der 90er eine sog PAE (physical address extension) vorhanden ist, als Faustregel kann man davon ausgehen, daß alle 32bit Prozessoren, die in Systemen sitzen die auch nur annäherungsweise sinnvoll die 4GB VM Grenze erreichen können, jedem Prozess diese auch ermöglichen können - auch wenn weniger als 4GB RAM vorhanden sind (dank Swap).
Non-x86 sind natürlich eine andere Sache, aber andererseits haben wir im x86 Bereich seit 2004 auch 64bit, sowohl bei den gängigen OS (Linux, XP64), als auch bei der Hardware.
Heutzutage hat man üblicherweise dank Memory Compression, Deduplication und Overcommit virtuell ohnehin mehr addressraum zur verfügung, als sich aus RAM+Swap ergibt.
Bei 32bit Programmen kann der GPU Speicher oft ohnehin nicht komplett in den address space eingeblendet werden, da würde ja gar kein Platz mehr übrig bleiben für das Programm zum laufen. Entsprechend muß die GPU anders befüllt und bedient werden. Gleiches auch für memory mapped files, die faktisch schwierig werden, will man nicht eine Vielzahl von Prozessen spawnen (die unter Windows wiederum probleme mit konkurrierenden Zugriffen auf Files bekommen können).