Ich betreibe ein Windows 10 in einer qemu/kvm VM unter Mint 19.
Das System ist ein Upgrade von einer gut laufenden W7-Installation, der
vorgegebene Arbeitsspeicher von 3478 MiB scheint aber für W10 zu klein
zu sein – die Kiste swapt sich tot.
Ich habe die Maximum Memory Allocation in qemu/kvm zwar auf 6166 MiB
hoch gesetzt, das wird aber von Windows nicht genutzt.
Wie kann man dem doofen Ding beibringen, dass es noch mehr Speicher
gibt?
Jetzt habe ich die Mühle einfach mal runter gefahren und die Current
Allocation auf 6166 gesetzt und siehe da, die Mühle läuft schon deutlich
flüssiger…
Klar kann man, egal ob physisch oder virtuell, zig GB an RAM
reinstopfen. Die Frage ist aber, wieviel RAM dein 32-Bit-Betriebssystem
adressieren kann. Da macht auch physikalisch oder virtuell keinen
Unterschied.
W.P. schrieb:> Klar kann man, egal ob physisch oder virtuell, zig GB an RAM> reinstopfen. Die Frage ist aber, wieviel RAM dein 32-Bit-Betriebssystem> adressieren kann. Da macht auch physikalisch oder virtuell keinen> Unterschied.
GENAU das meine ich.
Was den Speed-Zuwachs angeht.
Die VM-Maschine stellt den Ram zu Verfügung den du angibst. Ist der Wert
höher als ECHTER RAM - 2-3 GB geht die Auslagerung da schon los.
Nun bekommt sie Gesagt, Da ist ein Win-32Bit drauf. Ergo übergibt sie
etwas weniger wie 4 GB an den Arbeitsspeicher. Und die restlichen Ram.
;) Naja du hast ja in der VM keine ECHTE Grafikkarte. Also bekommt
Windows mit den Grafikkartentreiber RAM zuerkannt der NICHT zu Windows
gehört.
Damals gab es Boards die einfach 128 MB echten Grafikkarten-Speicher
hatten und den Rest von Hauptspeicher klauten. War mehr als 4 GB da,
hatte Windows 4 GB minus ein bisschen Verwaltung und der Rest wurde
einfach vom Bios der Grafikkarte zugewiesen.
Auch kann es sein, das deine VMM den überflüssigen ZUGEWIESENEN RAM
einen Internen CHACHE-Speicher (ne Art Ramdisk für arme) zuweist.
Unter DOS / ersten Windows Versionen machte man das mit Smartdrv-treiber
in der Config.sys. Auch Speicher den das OS nicht gefunden hat, weil
gesperrt.
Das muss man so machen, weil du aus der VMM ja nicht raus kommen sollst.
SANDBOX-PRinzip.
Ich hatte vor den 6166 MiB Current eine Zwischenstufe mit 4100 MiB
eingeschaltet – die brachte etwas Verbesserung. Erst die Allokation von
6166 MiB lies die VM wieder erträglich schnell laufen. Irgendwie scheint
qemu/kvm PAE bereitzustellen und W10 scheint es zu nutzen.
Klarheit bringt der Screenshot vom W10-Resourcen-Monitor…
Genau. Egal wie du das Zusammenrechnest es sind 3 GB.
Deine Spielchen Konfigurieren die VMM. NICHT den Speicher von Windows.
Wie geschrieben ich vermute ein Smartdrv /Chache oder wie auch immer den
die VMM da einsetzt.
Unter alten Windows ging das so.
mit Smartdrv.exe in der Config.sys Speicher abzapfen. Der fehlte Windows
ergo war er nicht da. ABER. Dieser Speicher wurde vom überlagerten
System genutzt, ähnlich einer RAM-DISK. Das Resultat war ein schnelleres
Arbeiten weil die Cache-Daten an den Smartdrv übergeben wurden, und
Windows was besseres zu tun hatte, während der Smartdrv-Treiber die
Daten gemütlich auf die Festplatte schaufelte.
Und die VMM macht da sicher was ähnliches. Besonders da i.d.R. viel
ECHTER RAM zur Verfügung steht. Man muss es ihr nur erlauben. ;) Was
auch Sinn macht, denn man will ja nicht nur die VMM laufen haben sondern
noch andere Software (meist noch eine VMM).
Fakt ist : Win-32Bit ist bei 4 GB schluss. Das kannst du sogar
nachrechnen.
Frage : Wie viel Speicherstellen kann man mit 32 Bit ansprechen.
Taucher schrieb:> Klarheit bringt der Screenshot vom W10-Resourcen-Monitor…
und der besagt, dass Windows 3071 MB benutzt und weitere 3095 MB für
"Hardware" reserviert ist, also dein 32-Bit-OS nur 50% des Speichers
benutzt.
Verringere doch den RAM um 1 GB und vergleiche es mit diesem Screenshot.
Da wird dann irgendwas von "Gesamt 3071 MB" und "Installiert ~5166 MB"
stehen.
3095 MB für Hardware ist zu viel, auf meinem PC sind es nur 95MB.
Bei 3478MB waren dann ja nur noch 383MB für Windows übrig.
Da muß irgendwas an der Konfiguration nicht stimmen.
Ist ja leicht zu testen, wenn man eine 32-Bit Win10 VM rumliegen hat,
VMware. Wenn ich für die 8 GB RAM definiere, dann sind 5 GB "Für
Hardware reserviert", werden also nicht genutzt.
Die Systeminformation vermeldet: Installierter physischer Speicher 8 GB,
gesamter physischer Speicher 3 GB.
Peter D. schrieb:> Da muß irgendwas an der Konfiguration nicht stimmen.
Wie oben schon geschrieben wurde, nutzt ein 32-Bit Windows nur einen
32-Bit Adressraum, kann also mit zu viel RAM nichts anfangen. Es könnte
prinzipiell mehr, wenn es denn wollte. Es will aber nicht, weil
Microsoft das für die non-Server so entschieden hat.
Erwin D. schrieb:> (prx) A. K. schrieb:>> Es könnte prinzipiell mehr, wenn es denn wollte.>> Wie geht das mit 32bit?
Indem die MMU mehr physikalische Adressbits produziert, als ein Prozess
adressieren kann: PAE. Die Summe der Prozesse könnte mehr RAM nutzen,
als jeder alleine.
Der Windows-Kernel arbeitete anno XP nicht mit PAE, tut es aber
mittlerweile. Das ergab sich aus der Vereinheitlichung mit den Windows
Servern.
(prx) A. K. schrieb:> Das ergab sich aus der Vereinheitlichung mit den Windows> Servern.
Und aus dem nur mit PAE verfügbaren NX Bit, um den Schmutzfüssen die
Arbeit zu erschweren.
Peter D. schrieb:> 3095 MB für Hardware ist zu viel, auf meinem PC sind es nur 95MB.> Bei 3478MB waren dann ja nur noch 383MB für Windows übrig.> Da muß irgendwas an der Konfiguration nicht stimmen.
Du musst das richtig lesen.
W.P. schrieb:> dass Windows 3071 MB benutzt und weitere 3095 MB für> "Hardware" reserviert ist
Von den zugewiesenen 6166 MB verwendet Windows 3071 MB als RAM. Der
übrige Speicher, hier 3095 MB, ist für Hardware reserviert da er nicht
genutzt werden kann.
Genau genommen sind von den 3095 MB tatsächlich noch einige MB für
Hardware reserviert, der Großteil jedoch bleibt ungenutzt da er von dem
32-Bit-Windows nicht Verwaltet werden kann.
W.P. schrieb:> Von den zugewiesenen 6166 MB verwendet Windows 3071 MB als RAM. Der> übrige Speicher, hier 3095 MB, ist für Hardware reserviert da er nicht> genutzt werden kann.
Jein. mit Trick 17 schon.
Das bekannteste Beispiel ist eine RAM-Disk. Da Windows die nicht
adressiert das macht nämlich der Treiber) kann man diese für Windows(Als
flüchtige Festplatte) nutzen.
Die andere mehr o. weniger bekannte Variante ist : shared-memory
Wurde häufig eingesetzt um Ram zu sparen, kann man aber auch einsetzen
um Ram zu verschwenden. ;) Wenn die Chips eh schon bezahlt sind, sollen
sie auch arbeiten ;)
https://www.experto.de/praxistipps/shared-memory-tappen-sie-nicht-in-die-speicherfalle.html
Es gibt noch einige Beispiele dieser Art. ABER !!!! Windows selbst kann
das NICHT adressieren, es muss die Kontrolle darüber an einen Treiber
abgeben und kann nur über diesen Treiber Zugang finden.
Schlaumaier (Gast)
>W.P. schrieb:>> Von den zugewiesenen 6166 MB verwendet Windows 3071 MB als RAM. Der>> übrige Speicher, hier 3095 MB, ist für Hardware reserviert da er nicht>> genutzt werden kann.>Jein. mit Trick 17 schon.>Das bekannteste Beispiel ist eine RAM-Disk. Da Windows die nicht>adressiert das macht nämlich der Treiber) kann man diese für Windows(Als>flüchtige Festplatte) nutzen.
32bit-Windows kann das adressieren, wenn es PAE unterstützt.
Ob das bei den normalen Windows-Editionen für's normale Volk bereits
standardmäßig aktiv ist, weis ich nicht - aber grundsätzlich sollten die
das heute wohl können.
Es kann aber diesen Adressraum nicht direkt einem einzelnen Prozess
verfügbar machen. Es kann aber mehrere Prozesse über diesen Adressraum
verteilen.
Ein Prozess kann aber diesen größeren Adressraum trotzdem nutzen, und
zwar als extended Memory, oder in windows-deutsch AWE. Dazu müssen die
Programme aber AWE verstehen, so wie damals die DOS-Programme EMM, high
Mem und andere Memoryextender verstehen mussten.
Und mit shared Memory hat das nix zu tun, der ohnehin nur in den ersten
4GB des RAM stattfinden kann (das, was Du da verlinkt hast, ist aber
eine andere Variante von shared Memory, was eher eine Beschißvariante
ist).