Nach meinen bescheidenen Kenntnissen funktioniert die Speicherverwaltung bei 2.6 anders - aber sehr gut. Man kann sich lediglich nicht (mehr) absolut auf den Wert bei free verlassen. Beispiel (was ich in meinem ersten Posting schon mal anführte):
Mein laufendes System (2 Tage mit Suspend):
[root@tux1 gerhard]# free
total used free shared buffers cached
Mem: 1294768 1066940 227828 0 8 599684
-/+ buffers/cache: 467248 827520
Swap: 2441840 0 2441840
Also ca. 467MB benutzt laut free. Das deckt sich aber nicht real mit den Summen der RES-Spalten wenn ich die "dicken" und kleinen Prozesse bei top/htop addiere.
Jetzt eine ramfs erstellt und Speicher darin belegt:
mkdir /ramfs
mount -t ramfs none /ramfs
dd if=/dev/zero of=/ramfs/dd bs=1M count=600
Ich habe hier 600MB gewählt, wichtig ist halt das man mit dem Wert das System eben nicht zum Swappen bringt. Die Größe also so wählen das sie reichlich unter dem Wert von (Gesamtes RAM minus buffers(momentan genutztes Ram laut free)) bleibt.
umount /ramfs
gibt nun den Speicher der RamFS wieder frei. Und nun zeigt free hier:
[root@tux1 gerhard]# free
total used free shared buffers cached
Mem: 1294768 327752 967016 0 8 98976
-/+ buffers/cache: 228768 1066000
Swap: 2441840 60 2441780
Also -buffers zeigt hier einen deutlich geringeren Wert an. Trotzdem sind die offenen Applikationen (mit ihrem Speicher) genau die gleichen. Auch wurde nicht geswappt.
Was sich deutlich verändert hat ist der Wert bei cached (klar: IO-cache wurde verworfen da ja real - durch die ramdisk - Speicher gebraucht wurde). Dies löste aber im Kernel auch das aus, was ich mit GarbageCollector bezeichnete: Der Kernel räumt seinen Speicher (z.B. die DirtyPages) auf, da er durch die Spiecheranforderung einen Grund hatte. Ohne das hätte mir free evtl. noch stundenlang den "falschen" Wert anzeigen können.
Meine Schlußfolgerung (wenn es also darum geht wie: Hey, mein System zeigt laut top/htop/free oder Tools wie KDE/Gnome-Anzeigen nach einigen Stunden viel gebrauchten Speicher an):
- diese Werte müssen nicht das real nutzbare freie Ram widerspiegeln.
- der Kernel bereinigt diese Werte erst, wenn es einen Grund gibt (obigen Effekt kann man auch beobachten wenn man ein "großes" Programm startet und hat manchmal während oder nach Beendigung mehr "freies" Ram als vorher)
- Speicherverwaltung in 2.6. sind sehr effektiv (es gibt sogar Algorithmen zur Speicherdefragmentierung IMHO)
- Speichermangel ist wirklich erst feststellbar (wie früher auch) wenn langfristig, dauernd und reproduzierbar geswappt wird
- Auch nach Beenden der Prozesse (mein Ursprungsbeispiel) muß der "freie" Ram bei free oder /proc/meminfo nicht unbedingt zutreffen. Bei Anforderung stellt der Kernel den Ram zur verfügung (bzw. reorganisiert seine Verwaltung daß der maximal Mögliche zu diesem Zeitpunkt vorhanden ist.
Weiterhin (noch ein nettes "Denkbeispiel"): Anwendungen scheinen je nach Ram-Ausbau initial unterschiedlich Speicher anzufordern bzw. zu bekommen.
a) KDE4.1 auf meinem PC (1256MB RAM, nvidia mit compisite)
"Verbrät" nach dem Start in KDE ca. 280MB
//Edit: nicht kde allein, sondern eben was free bei -buffers als "belegt" meldet.
b) Laptop (256MB Ram, S3 ohne composite)
Braucht für KDE mit den gleichen Progs/Anordnung "nur" 150MB
(beide Werte momentan nur aus dem Kopf, wenn ich beides mal restarte reiche ich die realen Werte nach. Und nein: ich würde auf meinem T22-Laptop nie kde4.1 laufen lassen...)
Bei beiden KDEs war 1 dolphin und ein Konqueror gestartet und 1 Plasmaoid auf dem Desktop aktiv, Desktop-Effekte abgeschaltet.
Also ein deutlicher Unterschied, der IMHO nicht allein durch die Grafikhardware/Treiber erklärbar ist.
Meine Vermutung (als Laie): Programme belegen vorsorglich mehr Speicher für "zukünftige" Aktionen je nach verfügbarem RAM bzw. was der Kernel zuteilt. So das z.B. Strukturen für einen 2. Browser-Tab schon "vorinitialisiert" sind und somit schneller ausführbar.
Weiterhin muß der Kernel natürlich den Speicher schneller "reorganisieren" (obige These) wenn der Gesamt-Ram geringer ist.