compcache - compressed in-memory swap device for Linux

[eworm]

Hallo zusammen!

Ganz schön ruhig hier heute... Warten alle auf irgendwelche News? :unsure: :-D

Ok, will ich mal wieder für ein wenig Diskussionsstoff sorgen. Ich habe gerade ein interessantes Projekt aufgestöbert: compcache - compressed in-memory swap device for Linux

Die Idee dabei ist ein Swapdevice im RAM anzulegen, in das die Daten komprimiert abgelegt werden. Geht dem System also der Speicher aus werden Daten komprimiert und wieder in den RAM gelegt, der unkomprimierten Speicher kann dann freigegeben werden. Werden die Daten wieder gebraucht werden sie einfach dekomprimiert und können dann wieder gebraucht werden. Gerade für die Pandora dürfte das interessant sein - vor allem wenn man das kleine Ding als Netbook benutzen und viele Programme gleichzeitig starten will. Das Komprimieren und Dekomprimieren kostet zwar etwas Rechenleistung, es dürfte aber immernoch schneller sein als die Daten irgendwo auf Flash-Speicher zu schreiben - und besser für NAND und SD-Karten ist es allemal.
Ich werde das auf jeden Fall mal ausprobieren wenn es so weit ist. Bin schon echt gespannt...

Schöne Grüße
Chris

 

[Lockenlord]

Eine Swap-Partition ist ja dafür gedacht gerade nicht gebrauchte Daten aus dem Arbeitsspeicher auf der Festplatte auszulagern, mit diesem Programm werden also Daten aus dem Arbeitsspeicher im Arbeitsspeicher abgelegt. :lol:
OK, ernsthaft, die Idee ist auf jeden Fall gut, aber ich kann mir gut vorstellen, dass es nur dann wirklich was bringt, wenn man im Desktopbetrieb viele Programme parallel laufen haben will. Dann muss ein schneller, möglichst effizienter Kompressionsalgorithmus her, damit die Pandora nicht merklich langsamer wird und die Daten beim Komprimieren trotzdem deutlich kleiner werden. Dann ist die Frage, wie viel Speicher das Programm selbst zum Komprimieren braucht und ob und wie viel Speicher man dafür reservieren muss.
Kann irgendjemand sagen, wie sich das Programm so macht und ob dem höheren Energieverbrauch auch eine bessere Leistung gegenübersteht?

 

[Anonymous]

Dann muss ein schneller, möglichst effizienter Kompressionsalgorithmus her, damit die Pandora nicht merklich langsamer wird und die Daten beim Komprimieren trotzdem deutlich kleiner werden. Dann ist die Frage, wie viel Speicher das Programm selbst zum Komprimieren braucht und ob und wie viel Speicher man dafür reservieren muss.
Kann irgendjemand sagen, wie sich das Programm so macht und ob dem höheren Energieverbrauch auch eine bessere Leistung gegenübersteht?

Ohne den Link angeguckt zu haben, gehe ich eine Wette ein, dass da einfach der beliebte gzip-Algorithmus verwendet wird, der dann auf Speicherseiten angewendet wird. ARM-Code lässt sich ziemlich gut komprimieren, ich schätze, da müsste so ein Gewinn von durchschnittlich 40 bis 60% möglich sein, wenn Code aus dem Arbeitsspeicher in den komprimierten Swap-Arbeitsspeicher geschoben wird. Die Implementierung der Algorithmen dürfte so im niedrigen zweistelligen Kilobytebereich liegen, also wirklich fast keinen Arbeitsspeicher belegen. Aber irgendwie erinnert mich das an die verschiedenen Mem-Doubler-Scherze auf dem Amiga und dem PC...

 

[eworm]

Nicht ganz, es wird LZO benutzt.
Beim Rest muss ich dir aber zustimmen... Vom Speicherplatz braucht der Kram selbst kaum was. Wirklich effizient getestet habe ich es aber noch nicht, zu viel RAM im Notebook. Vielleicht sollte ich mal mit MEMSIZE=256MB booten. :rotfl:

Die Mem-Doubler-Scherze sind mir irgendwie entgangen... War wohl vor meiner Zeit. Was hatte es denn damit auf sich?

 

[MiniSinisterMinister]

Wenn ich das richtig verstehe, dann hat das den gleichen Effekt wie das temporäre Swappen von Daten aus dem Hauptspeicher auf die Festplatte. Bei einem System mit eigentlich zu kleinem Speicher können so Programme laufen, die eigentlich für mehr Hauptspeicher ausgelegt sind. Allerdings wird das Arbeiten dann ziemlich zäh. Es ist also eher eine Notlösung für zu schlecht ausgestatte Systeme. Wenn das hier vom Prinzip her genauso funktioniert und dieselben Nachteile hat (stark spürbare Verzögerungen), dann würde ich eher kein Programm nutzen wollen, das darauf angewiesen ist bzw. einfach auf mehrere geöffente Programme gleichzeitig verzichten.

 

[eworm]

So, ich quäle gerade mein Notebook ein wenig... :juhu:

Also gebootet habe ich mit dem Kernelparameter mem=256M - mein System läuft also tatsächlich nur mit 256MB RAM. Der erste Login war echt hart... Alles was so im Hintergrund läuft, und dann von KDM in ein komplettes KDE 4.3 einloggen. :dash:
Also wieder ausgeloggt, apache und mysql gestoppt (läuft immernoch genug Blödsinn...) und compcache aktiviert. Und siehe da, es ist zwar kein Geschwindigkeitswunder, funktioniert aber. Ich bin jetzt in KDE eingeloggt, habe Konsole und Konqueror auf und schreibe diese Post.

Interessant finde ich die Statistik dazu. Ich habe compcache aktuell mit BackingSwap aktiviert, was compcache nicht komprimieren kann oder will kann es so tatsächlich auf die Swap-Partition schreiben. Es gibt aber trotzdem deutlich mehr Aktivität im RAM als auf Platte. Bemerkenswert finde ich die Zeilen mit dem DataSize... Es schein tatsächlich ein Verhältnis von 4:1 von unkomprimierten zu komprimierten Daten zu geben.

BackingSwap:    /dev/mapper/vg-swap
DiskSize:        2097152 kB
MemLimit:          37828 kB
NumReads:          12693
NumWrites:         32835
FailedReads:           0
FailedWrites:          0
InvalidIO:             0
ZeroPages:          2879
GoodCompress:        100 %
NoCompress:            0 %
PagesStored:       22264
PagesUsed:          5735
OrigDataSize:      89056 kB
ComprDataSize:     22701 kB
MemUsedTotal:      22940 kB
BDevNumReads:       3653
BDevNumWrites:      7692

Ich glaube gleich versuche ich mal XFCE ohne KDM davor. Ich denke mit der Pandora lässt sich doch schon so einiges machen. ^_^

 

[Lockenlord]

Hast du schon geguckt, wie sich das Programm auf die Akkulaufzeit auswirkt?

 

[Morchel]

Also wieder ausgeloggt, apache und mysql gestoppt (läuft immernoch genug Blödsinn...) und compcache aktiviert.

Heißt also, dass compcache während der Sitzung ohne Komplikation gestartet und und beendet werden kann (nur um nochmal sicher zu gehen)?
Gerade, wenn man vielleicht seltener den RAM "überreizt" (wird sich ja erst zeigen, wenn man das Gerät verwendet) praktisch. So aktiviert man das ganze nur dann, wenn es wirklich nötig ist. Vor allem auch dann, falls es merklich Akku frisst, wie Lockenlord ebenso befürchtet.

 

[eworm]

Hast du schon geguckt, wie sich das Programm auf die Akkulaufzeit auswirkt?

Nein, keine Ahnung was sich da tut. Ist die Frage ob sich das so genau bestimmen lässt... Aber ich denke das Bisschen Rechnen braucht nicht so viel Strom wie das Schreiben und Lesen von/auf Platte.
Und bei einem ARM-Prozessor mache ich mir da eh wenig Sorgen...

Heißt also, dass compcache während der Sitzung ohne Komplikation gestartet und und beendet werden kann (nur um nochmal sicher zu gehen)?
Gerade, wenn man vielleicht seltener den RAM "überreizt" (wird sich ja erst zeigen, wenn man das Gerät verwendet) praktisch. So aktiviert man das ganze nur dann, wenn es wirklich nötig ist. Vor allem auch dann, falls es merklich Akku frisst, wie Lockenlord ebenso befürchtet.

Klar, du brauchst ja nur das Swap-Device wieder abschalten. Schiefgehen kann das nur dann, wenn du nicht ausreichend physikalischen RAM hast um die ausgelagerten Daten wieder einzulagern - dann musst du halt erstmal Programme beenden.

 

[Anonymous]

Nicht ganz, es wird LZO benutzt.

Aha. Habe gerade einmal nachgelesen, was das ist. Es ist ein weiteres Derivat des Ziv-Lempel-Algorithmusses, wie es übrigens auch gzip ist, also lag ich relativ nah. Diese Familie von Algorithmen ist einfach sehr gut geeignet für in etwa gleichschnelles Packen und Entpacken bei einem guten Verhältnis von Aufwand und Resultat.

Vom Speicherplatz braucht der Kram selbst kaum was.

Ich meine, gerade etwas von 5KB gelesen zu haben...

Die Mem-Doubler-Scherze sind mir irgendwie entgangen... War wohl vor meiner Zeit. Was hatte es denn damit auf sich?

Das waren so Programme, die irgendwelche Tricks ausgenutzt haben, um dem Betriebssystem und dem User vorzugaukeln, es wäre plötzlich mehr Speicher verfügbar. Dazu wurde dann eine wilde Geschichte erzählt, dass da schnelle Kompression und Dekompression benutzt wird, um mehr Speicher freizuhalten. Also im Grunde exakt das, was hier tatsächlich gemacht wird. Es gab sogar ein betrügerisches kommerzielles Programm für den PC, das diese Augenwischerei betrieben hat. Damals waren auch so Festplattenverdoppelerprogramme weit verbreitet. Die haben aber wenigstens auch tatsächlich funktioniert, so dass auf die Sache mit dem RAM mehr Leute hereinfallen konnten.

Hast du schon geguckt, wie sich das Programm auf die Akkulaufzeit auswirkt?

Ich kann mir kaum vorstellen, dass es da einen messbaren Effekt gibt. In der Doku zu LZO steht übrigens drin, dass eine auf 386 optimierte Variante, es auf ein Drittel der Geschwindigkeit eines einfachen memcpy() bringt, was ziemlich beachtlich ist. Da scheint allerdings von einem Pentium-133 die Rede zu sein, heutige Rechner (Taktverhältnis Prozessor/Speicher eher höher) könnten das noch schneller hinbekommen.

Da ich gerne (optimierten) Assemblercode programmiere und auf ARM auch einige Erfahrung habe, mache ich mir mal eine Gedächtnisnotiz, dass sich ein Blick auf den LZO-Kram als Ziel lohnen könnte...

 

[SebuSoft]

Das waren so Programme, die irgendwelche Tricks ausgenutzt haben, um dem Betriebssystem und dem User vorzugaukeln, es wäre plötzlich mehr Speicher verfügbar. Dazu wurde dann eine wilde Geschichte erzählt, dass da schnelle Kompression und Dekompression benutzt wird, um mehr Speicher freizuhalten. Also im Grunde exakt das, was hier tatsächlich gemacht wird. Es gab sogar ein betrügerisches kommerzielles Programm für den PC, das diese Augenwischerei betrieben hat. Damals waren auch so Festplattenverdoppelerprogramme weit verbreitet. Die haben aber wenigstens auch tatsächlich funktioniert, so dass auf die Sache mit dem RAM mehr Leute hereinfallen konnten.

Oh ja da kann ich mich auch noch dran erinnern die Programme hatten irgendeine System-Datei von Windows 3.x so ümgeschrieben das sie mehr RAM angezeigt hat sonnst aber nichts gemacht und dafür haben dann auch viele Leute noch Geld für bezahlt.... Abzocke hoch 10! Aber das mit der Festplatte hat natürlich funktioniert eines der Programme würde ja auch gleich mit DOS bzw. auch später bei win9x direkt von MS mitgeliefert DoubleSpace (später Drivespace weil es halt doch nicht ganz verdoppelt hat :-D) Hab ich damals bei meiner 512MB Festplatte benutzt :-D

Ich kann mir kaum vorstellen, dass es da einen messbaren Effekt gibt. In der Doku zu LZO steht übrigens drin, dass eine auf 386 optimierte Variante, es auf ein Drittel der Geschwindigkeit eines einfachen memcpy() bringt, was ziemlich beachtlich ist. Da scheint allerdings von einem Pentium-133 die Rede zu sein, heutige Rechner (Taktverhältnis Prozessor/Speicher eher höher) könnten das noch schneller hinbekommen.

Da ich gerne (optimierten) Assemblercode programmiere und auf ARM auch einige Erfahrung habe, mache ich mir mal eine Gedächtnisnotiz, dass sich ein Blick auf den LZO-Kram als Ziel lohnen könnte...

Jip die ganzen Lempel-Ziv-"derivate" sind ja echte optimierungs Wunder da sie ja nur einmal von Anfang zum Ende über die Daten gehen und auch sonst keine wirklich komplizierten Suchen/Vergleiche oder ähnliches benötigen. Geht mir nämlich genauso ich Liebe es einfach Assemblercode immer weiter zu optimieren und noch kleiner und noch schneller zu machen (auch wenn das natürlich nicht immer das selbe ist :-D ) den LZW hatte ich mir z.B. auch mal vorgenommen ich kann nun aber nicht mehr sagen wie die Ergebnisse waren ist zu lange her und ich hab das alles leider bei einem Festplattencrash Verloren... Falls du dich für sowas interessierst, kennst du die FNV Hash-Funktion? Auch so eine schöne kleine Funktion die man extrem gut in ASM optimieren kann.

Ok Sorry fürs OffTopic

Aber das wäre doch eigentlich keine Schlechte Idee mit diesem compcache. Ich denke das könnte wirklich Hilfreich sein damit wir nochmehr aus der Pandora herausholen können als eh schon. Klar braucht natürlich etwas Prozessorleistung aber ich denke wenn dann wird der RAM später eher das Problem sein, zumindest beim Arbeiten auf der Pandora mit mehreren Programmen gleichzeitig z.B. schreibt man mit Abiword ein Text will dafür mit Firefox etwas nachschauen und gleichzeitig dann vielleicht noch seine E-Mail's abfragen und Musik hören etc... Ich denke der Cortex würde das so hinbekommen aber FireFox z.B. ist ja nun nicht gerade für seinen geringen Speicherverbrauch bekannt! :-D

 

[Evil Azrael]

http://en.wikipedia.org/wiki/SoftRAM
Das ist das Programm. Das fiel mir auch direkt ein, als ich die Nachricht bei Heise las.

 

[Joker]

Eine Swap-Partition ist ja dafür gedacht gerade nicht gebrauchte Daten aus dem Arbeitsspeicher auf der Festplatte auszulagern, mit diesem Programm werden also Daten aus dem Arbeitsspeicher im Arbeitsspeicher abgelegt. :lol:

genau das habe ich mir auch gedacht...
Kann mir nochmal einer den Sinn erklären???

Mal ne andere Frage: Wie hoch ist denn die Übertragung vom RAM zum CPU und wie hoch die Übertragung von der SD-Karte zum CPU?

 

[retn]

Eine Swap-Partition ist ja dafür gedacht gerade nicht gebrauchte Daten aus dem Arbeitsspeicher auf der Festplatte auszulagern, mit diesem Programm werden also Daten aus dem Arbeitsspeicher im Arbeitsspeicher abgelegt. :lol:

genau das habe ich mir auch gedacht...
Kann mir nochmal einer den Sinn erklären???

Mal ne andere Frage: Wie hoch ist denn die Übertragung vom RAM zum CPU und wie hoch die Übertragung von der SD-Karte zum CPU?

Die Daten die in den Arbeitsspeicher gelegt werden sind komprimiert, d.h. du hast eine komprimierte Swap-Datei im Arbeitsspeicher.
Standardmässig werden 15% des Arbeitsspeichers als Swap genutzt und komprimiert, das ganze wird von "free" übrigens als Swap erkannt.

Test auf der Homepage von compcache zeigen bei VMs mit 512mb Ram mit compcache einen Geschwindigkeitsvorteil von 33% (http://code.google.com/p/compcache/wiki/scanbench)

Wie groß der Unterschied bei der Pandora ist müsste man mal testen.