vorweg: Das hier ist in keiner Weise wichtig. Ich war nur neugierig.
Ich habe gerade Bullseye auf meinem "Resterechner" installiert. Dieser hat folgende Eckdaten:
GPU: Nvidia GTX 950 (2GB VRAM)
CPU: Intel Core2Quad Q9550
Mainboard: Abit I-G31 (irgendein Bananenboard auf das der Q9550 nach Ausfall seines Originalboards umziehen musste; limitiert den RAM auf max. 3GB)
Nun besteht da ein klares Missverhältnis zwischen knappem RAM und ungenutzem VRAM und ich habe mich gefragt, ob man dem abhelfen könnte indem man Teile des VRAM als RAM oder Swap nutzt. Und siehe da, das geht offenbar im Prinzip. [1]
Im Archwiki werden zwei Methoden vorgestellt. Die erste nutzt das MTD-Subsystem des Kernels (was auch immer das sei), die zweite implementiert ein fuse-Dateisystem im VRAM und nennt sich passenderweise "vramfs". Ersteres habe ich schnell wieder verworfen, da auch meine GTX 950 wie die GPU im Wiki hier nur ca. 256MB VRAM hergeben würde.
Wie vramfs zu bauen und zu aktivieren ist, ist auf der github-Seite vorzüglich beschrieben und so kam ich problemlos bis zu dem Punkt als ich die Swap-Datei im vramfs erstellt und mit mkswap vorbereitet hatte. Beim Schreiben der rund 1,7GB großen Datei hatte ich übrigens eine Schreibrate mit dd von rund 400MB/s, ebenso beim Wiedeereinlesen nach /dev/zero.
Das Aktivieren der Datei scheiterte dann allerings mit folgender Meldung:
Code: Alles auswählen
swapon: swapfile has holes
Die übliche Lösungs dafür lautet, die Swap-Datei mit dd statt z.B. fallocate anzulegen. Aber genau das hatte ich ja getan. Eine Suche im Netz nach genau diesem Problem gestaltete sich schwierig und so kam mir zum Schluss die Idee, den Swap nicht direkt auf dieser Swap-Datei zu erzeugen, sondern ihr ein Dateisystem (hier ext2) zu verpassen, dieses zu mounten und dort wiederum eine weitere Swap-Datei anzulegen und dann jene als Swap zu nutzen.
Das war erfolgreich und der Swap ließ sich aktivieren. Dass dieses verschachtelte Kontrukt nicht gut für die Performance ist war mir klar. Die Schreibrate brach auch auf 70-100MB/s ein (mehr Verlust als ich erwartet hätte), die Leserate blieb aber bei ca. 300MB/s.
Nachdem die Trockentests erfolgreich absolviert waren, habe ich den RAM mit ein paar fetten Websites und Libreoffice gefüllt. Ich habe noch in top gesehen, wie der Swap im VRAM angekratzt wurde. (anderer Swap war zu der Zeit nicht aktiv). Aber als es wohl richtig damit losging den Swap zu nutzen fror das System ein (Desktop noch sichtbar, keine Mausbewegung mehr, kein VT-Wechsel möglich; Antwort auf Pings ja, Einloggen per ssh nein).
Es blieb nur noch das harte Auschalten, weshalb hier auch nur Prosa steht.
Hat schon mal jemand mit vramfs experimentiert und kann Aussagen zur Stabilität machen?
Oder weiß jemand wie man unter einem aktuellen Kernel das Aktivieren des Swap ohne die zusätzliche Krücke eines zweiten Images bewerksteligen kann?
Zur MTD-Lösung steht im Archwiki, dass man den VRAM für den X-Server künstlich begrenzen muss, weil sich sonst Grafik und Swap gegenseitig auf die Füße treten würden. Hätte ich das hier auch machen müssen? Ich hatte gut 256MB RAM für die Grafik freigelassen und vermute zumindest, dass die noch nicht aufgebraucht waren.
[1] https://wiki.archlinux.org/title/Swap_on_video_RAM
[2] https://github.com/Overv/vramfs
[3] https://bugzilla.kernel.org/show_bug.cgi?id=207585