# Suspend to Disk: RAM Verbrauch vorher dezimieren

## Finswimmer

Hi!

Ich weiss, dass Linux nicht verwendeten RAM nicht freigibt, sondern die Daten darin behaelt, denn sie koennten ja noch gebraucht werden.

Erst bei andersartigen Daten werden die vorherigen "freien" Bloecke ueberschrieben.

Nun aeussert sich das beim Suspend to Disk so, dass immer 1499Mb auf die Platte geschrieben werden muessen.

Und das, obwohl nur der Firefox, Kmail und Kopete mit einem Verbrauch (gemessen nach unmittelbarem Neustart) von ungefaehr 400Mb, laufen.

Nun moechte ich fuer so einen Spezialfall ein Kommando haben, mit dem eben doch nur der aktuell zwingend benoetigte RAM auf die Platte geschrieben wird.

Habt ihr da eine Idee?

Danke

Tobi

----------

## 69719

Versuch es mal mit folgendem Programm. Es holt sich Speicher und befüllt ihn, somit muss der freie Speicher von anderen Programmen herhalten. Die Variable size mußt du entsprechend anpassen. Was anderes würde mir erstmal nicht einfallen.

```

#include <stdio.h>

#include <malloc.h>

#include <string.h>

#define _1B ( 1 )

#define _1K ( _1B * 1024 )

#define _1M ( _1K * 1024 )

#define _1G ( _1M * 1024 )

int main( int argc, char *argv[] ) {

   char *buf;

   size_t size = _1G;

   printf( "allokiere speicher...\n" );

   if ( ! ( buf = malloc( size ) ) ) {

      perror( "malloc:" );

      return 1;

   }

   

   printf( "fuelle speicher...\n" );

   memset( buf, 0, size );

   printf( "weiter mit return...\n" );

   fgetc( stdin );

   printf( "speicher wird freigegeben...\n" );

   free( buf );

   return 0;

}

```

----------

## Finswimmer

Dann sähe der Speicher aber so aus: Firefox, Kopete, ganz viel selbst belegter Speicher = 1499Mb

Oder irre ich mich?

Dann müsste dieser selbsterstellte Speicher aber noch "freigegeben" werden, sodass das Hibernate Skript ihn nicht auf die Platte schreiben will.

Tobi

----------

## 69719

Nachdem du return drückst wird er vom Programm freigegeben und das Programm beendet. Dann sollte alles wieder frei sein.

```

escor@mars ~/cpp $ free -m

             total       used       free     shared    buffers     cached

Mem:          1252       1147        105          0         36        786

-/+ buffers/cache:        325        927

Swap:          956         83        873

escor@mars ~/cpp $ ./memtest

allokiere speicher...

fuelle speicher...

weiter mit return...

speicher wird freigegeben...

escor@mars ~/cpp $ free -m

             total       used       free     shared    buffers     cached

Mem:          1252        304        948          0          1         49

-/+ buffers/cache:        253        999

Swap:          956        124        832

```

----------

## Finswimmer

Super! Hab es eben getestet und es funktioniert gar prächtig!

Danke  :Smile: 

Tobi

----------

## Finswimmer

Gehe ich recht in der Annahme, dass das 1G die maximale Größe vom RAM ist, die das Programm zu leeren versucht?

Kann ich da auch 1,5Gb, also meinen gesamten Ram eintragen?

Danke

Tobi

----------

## firefly

verwendest du swsusp oder tuxonice für "suspend to disk"?

Denn Tuxonice unterstützt auch kompression des images bevor es auf die Platte geschrieben wird. Desweiteren scheint es selbst zu versuchen nicht benötigten Arbeitsspeicher vorher frei zu räumen.

----------

## 69719

```

size_t size = _1G * 1.5;

```

sollte gehen, erst ab 2GB sollte es Probleme machen, da es dann zu Ganzzahlüberläufen kommt.

----------

## 69719

Hier ist eine bessere Version von dem Programm. Es holt sich genau so viel Speicher wie frei ist + den Anteil der als Buffer und Cache genutzt werden.

http://homeunix.de/dropcache/

----------

## schachti

Was auch gehen sollte:

```
sync && echo 3 > /proc/sys/vm/drop_caches
```

----------

## 69719

 *schachti wrote:*   

> Was auch gehen sollte:
> 
> ```
> sync && echo 3 > /proc/sys/vm/drop_caches
> ```
> ...

 

Oder diese Methode, das einzigste was mich daran nur stört ist, dass vorher ein sync durchgeführt werden sollte.

----------

## schachti

Für den Anwendungszweck von Finswimmer ist das meiner Meinung nach sogar ein Vorteil, weil damit Datenverlust vorgebeugt wird (wenn beim Suspend was schiefgeht).

----------

## amne

 *escor wrote:*   

>  *schachti wrote:*   Was auch gehen sollte:
> 
> ```
> sync && echo 3 > /proc/sys/vm/drop_caches
> ```
> ...

 

Und zurückschalten sollte man danach auch wieder, oder?

Also ich verwende hibernate-script, und soweit ich das mitbekommen habe wird da sowieso (von hibernate-script, oder dem Kernel selber) einmal zusammengeräumt und unnötiger Kram aus dem Speicher geschmissen.

----------

## schachti

Nö, zurückschalten muss man da nichts - der Befehl löscht bei Aufruf alle Caches etc., aber eben nur einmalig.

----------

## Finswimmer

 *amne wrote:*   

>  *escor wrote:*    *schachti wrote:*   Was auch gehen sollte:
> 
> ```
> sync && echo 3 > /proc/sys/vm/drop_caches
> ```
> ...

 

Habe es nun schon ungefähr 5mal getestet mit der allerersten Methode. Gegenüber dem normalen hibernate-script merke ich deutliche Vorteile.

Sonst war der RAM immer komplett belegt, nun werden immer nur 500Mb auf die Platte geschrieben.

Ich denke, ich werde Schachtis Methode verwenden bzw mal Escors Variante testen, denn den Buffer zu leeren könnte auch noch einen Geschwindigkeitsvorteil bringen.

Tobi

----------

## manuels

 *firefly wrote:*   

> verwendest du swsusp oder tuxonice für "suspend to disk"?

 Kurze Zwischenfrage: hat jemand von euch Erfahrungen mit swsusp?

Bei mir stürzt tuxonice beim Aufwachen von Suspend to Disk ab.

Ist swsusp da stabiler?

----------

## mrsteven

Das ganze ist immer noch eine recht wackelige Angelegenheit, hier eine funktionierende Kombination aus Kernel, X und eventuell noch zusätzlichen Treibern zu finden ist leider oft Glückssache.  :Confused: 

----------

## firefly

 *manuels wrote:*   

>  *firefly wrote:*   verwendest du swsusp oder tuxonice für "suspend to disk"? Kurze Zwischenfrage: hat jemand von euch Erfahrungen mit swsusp?
> 
> Bei mir stürzt tuxonice beim Aufwachen von Suspend to Disk ab.
> 
> Ist swsusp da stabiler?

 

sicher das tuxonice abstürzt oder eher ein Treiber der noch nicht sauber suspend unstertützt (beliebte kandidaten sind die binary treiber von nvidia und ati).

----------

## manuels

hast recht. Ist der Nvidia-Treiber - ist die neueste Version.

Die werden es wohl nie schaffen einen ordenlichen hibernate-kompatibelen Treiben zu programmieren.   :Rolling Eyes: 

----------

