kernel patches: 2.6.19.2 compcache 0.5.4

[abraXxl]

Hallo,

bei meinen Freetz- und Sp2Fr-Experimenten sind Patches für den Kernel 2.6.19.2 entstanden. Ich habe compcache 0.5.4 in den Kernel intergriert. Das ist die letzte Version die auf 2.6.19 laeuft.

Kurz: Compcache zwackt sich etwas Hauptspeicher ab und bietet diesen als komprimiertes Swap-Device an. Sehr praktisch für Memory-Contrained-Systems.
Mehr dazu hier.

Unter x86 habe ich dies lange im Einsatz. Die Patches integrieren es und kompilieren sauber durch.

Config.in usw. habe ich noch nicht angepasst, d.h. da Module explizit geladen werden müssen, macht der Patch erstmal nix.

Ich würde mich freuen wenn der Patch auf genommen wird.

cya

EDIT: Anhang aktualisiert

 

[RalfFriedl]

Was für Kompressionsraten erreicht man denn damit? Lohnt sich das wirklich?

 

[abraXxl]

Compcache nutzt als Compressionsalgorithmus LZO.

Ich habe im Patch aus 2.6.23 den LZO Algorthmus backportet, es muesste AFAIK LZO1X-1 sein. LZO ist fix und komprimiert Binärdaten i.d.R zu ca 51% Rest.

IMO Lohnt sich dies:
1. Der Kernel versucht, wenn Prozesse _lange_ inaktive Pages haben (LRU) die Pages auszulagern. Ist kein Swap da macht er das nicht. Jetzt ist Swap da, wir also wieder freien Speicher gewonnen.
2. Das Compcache Swapdevice belegt nur den Speicher, den der comprimierte Inhalt wirklich benötigt.

Alles in allem wir haben mehr allozierbaren Speicher, für ggf. für weitere Programme und Daemons.
Und dafür haben wir Freetz

cya

 

[Silent-Tears]

Jups, das PRozedere hilft. Kostet zwar einen Deut Performance - logisch, ne? - aber brachte auf meinem Handy durchaus Performancegewinn im Vergleich zu einer Swap-Partition.

 

[markuschen]

Das klingt ja sehr interessant, würde aber auf einer schmalbrüstigen Box wie z.B. einem meiner Sorgenkinder - der 7113 mit 16 MB Ram - richtig Sinn machen.
Gäbe es eine Möglichkeit, den Patch für Kernel 2.6.13.1 zu implementieren?

 

[abraXxl]

Leider nicht ohne größeren Aufwand und Kenntnis von interna des Kernels.

Version 0.5 von Compcache setzt mindestens laut Doku 2.6.17 (neue Futex-API) vorraus. Ich habe vor einiger Zeit brereits versucht dies für den Targe500W/Speedport (2.6.13.1) zu komplieren. Es passt aber sehr viel nicht, und fehlt viel. Siehe Kommnetare zu http://code.google.com/p/compcache/wiki/CompilingAndUsing

BTW Es gibt jetzt ein Ticket dazu.

 

[olistudent]

# mknod /dev/ramzswap0 b 253 0
# swapon /dev/ramzswap0
# dd if=/dev/zero of=dd.tmp bs=1M count=40
# free
              total         used         free       shared      buffers
  Mem:        61300        58380         2920            0           32
 Swap:        15316         2044        13272
Total:        76616        60424        16192

Funktioniert. Was ich jedoch nicht verstehe. Warum hat die Box mit count=50 einen Reboot hingelegt, weil ihr der Speicher ausgegangen ist. Müsste das nicht komprimiert werden? Oder kann der das nicht komplett auslagern?

MfG Oliver

 

[abraXxl]

Eigentlich müsste er /dev/zero gut komprimieren können. Was er da macht weis ich nicht genau. Ein kernel-log wäre gut.

 

[abraXxl]

1. /var ist standardmässig nur mit 32MB (auf 64MB boxen) gemountet, warum du dann überhaupt 40 bzw. 50MB drauf schreiben kannst ist mir ein Rätsel

2. AVM hat im Kernel den OOM-Killer deaktiviert. Memory-overcommit führt danach automatisch zum Neustart, wenn ich das richtig verstehe. (CONFIG_DISABLE_OOM_KILLER=y, ich finde nur auf die Schnelle keine weitere verwendung des Macros in Kernel-Tree, sonst könnte versuchen mehr zu sagen)

3. hier mein Exempel auf meiner 7570 im laufenden Betrieb.

modprobe lzo_compress
modprobe lzo_decompress
modprobe xvmalloc
modprobe ramzswap disksize_kb=16384 memlimit_kb=16384
# noetig da der vinax schon block major 253 belegt bei mir
mknod /dev/ramzswap0 b $(awk '/ramzswap0/ {print $1}' /proc/devices) 0
swapon /dev/ramzswap0
free

cd /var
mkdir foo
# tmpfs mit 128MB (!) mounten, /var hat standard mässig nur 32MB auf 64MB Boxen
mount -t tmpfs -o size=$((128*1024*1024)) foo foo
cd foo
df

# 43MB schreiben
dd if=/dev/zero bs=$((1024*1024)) count=48 of=dummy

free
df

Et voila box bleibt funktional, internet und POTS/ISDN-telefonie dananch noch möglich
Mit nur 43MB ging sogar noch SIP-Telefonie, ohne stack-trace-Orgien.
Lässt man dass "swapon /dev/ramzswap0" macht meine 7570 schon bei einem dummy von 32 MB einen Spagat (Strack-Traces bis zum Power-Cycle)
Ab einem Dummy von 50 MB, wird es langsam und irgendwann hagelt Stack traces.
AVM hat BTW den OOM-Killer im Kernel ausgemacht. Das mag dieser nicht so gerne.

Ich würde behaupten er Patch funktioniert, warum er /dev/zero nicht besser komprimiert weis ich nicht.
Ich vermute er lagert das File noch nicht aus sondern Teile des AVM-Binär-Zoos, da das File noch "in use" ist. Beim Swappen im Kernel wird unter anderem LRU verwendet.

EDIT1:

for i in `seq 1 1 43`; do dd if=/dev/zero bs=$((1024*1024)) count=1 of=$i; done

Ist etwas schicker man sieht von der Ausgabe von dd her wann er komprimiert.
Ausserdem sieht man wenn man alle die Files wieder löscht, das er AVM-Binäries ausgelagert hat.

 

[RalfFriedl]

Beim Swappen im Kernel wird unter anderem LRU verwendet.

Das sollte sich ja prüfen lassen:
10MB Datei anlegen, 10 Minuten warten, dann das Ganze einige Male wiederholen.

 

[olistudent]

1. /var ist standardmässig nur mit 32MB (auf 64MB boxen) gemountet, warum du dann überhaupt 40 bzw. 50MB drauf schreiben kannst ist mir ein Rätsel

Wie kommst du da drauf?

MfG Oliver

 

[abraXxl]

tmpfs wird, wenn ohne Mountoptionen gemounted mit einem Limit von der Hälfte des Gesamthauptspeichers belegt.

/var # dd if=/dev/zero bs=$((1024*1024)) count=31 of=dummy
dd: writing 'dummy': No space left on device
31+0 records in
29+1 records out
31080448 bytes (29.6MB) copied, 0.609220 seconds, 48.7MB/s
/var # ls -la dummy
-rw-r--r--    1 root     root      31080448 Jan  1 01:17 dummy
/var # dd if=/dev/zero bs=$((1024*1024)) count=33 of=dummy 
dd: writing 'dummy': No space left on device
31+0 records in
29+1 records out
31080448 bytes (29.6MB) copied, 0.577040 seconds, 51.4MB/s
/var # ls -la dummy
-rw-r--r--    1 root     root      31080448 Jan  1 01:17 dummy

Die Dateigröße ändert sich nicht. Trotz count mit 2MB mehr

 

[olistudent]

/var/mod/root # dd if=/dev/zero bs=$((1024*1024)) count=31 of=dummy
31+0 records in
31+0 records out
/var/mod/root # dd if=/dev/zero bs=$((1024*1024)) count=33 of=dummy
33+0 records in
33+0 records out
/var/mod/root # free
              total         used         free       shared      buffers
  Mem:        61300        57480         3820            0          500
 Swap:            0            0            0
Total:        61300        57480         3820
/var/mod/root #

Bei mir tut das so.

MfG Oliver

 

[abraXxl]

Ooo( mein Fehler ):
Ich habe bei mir aus Gewohnheit im Kernel: " Use full shmem filesystem " (CONFIG_SHMEM=y) drin. Daran beist er sich. Okay im Standardfall hast du Recht.