SWAP statt irgendwelcher RAM-Optimierungen?

Obwohl ich swap anhabe, wird bei mir opera trotzdem direkt geschlossen und die tabs laden immer neu
Hab jetzt zusätzlich noch mit autokiller memory optimizer die werte bei denen android sachen aus dem speicher wirft relativ weit runter gesetzt und die swappiness zum testen auf 100 gesetzt.
 
Zuletzt bearbeitet:
marcero schrieb:
Obwohl ich swap anhabe, wird bei mir opera trotzdem direkt geschlossen und die tabs laden immer neu
Hab jetzt zusätzlich noch mit autokiller memory optimizer die werte bei denen android sachen aus dem speicher wirft relativ weit runter gesetzt und die swappiness zum testen auf 100 gesetzt.

hast du mal beispieslweise mit dem Befehl "free" geprüft, ob der SWAP wirklich aktiv war? Wenn du da jetzt mit autokillern etc. anfängst, dann weiß nicht nicht, was das für Wechselwirkungen hat.
 
PatrickFries schrieb:
Da die Sache mit dem SWAP für mich überraschend ziemlich gut funktioniert (abgesehen von dem Standby-Problem) werde ich in die Richtung Compcache nix probieren. Aber ich habe natürlich nix dagegen, wenn sich jemand anderes dem Compcache mal annimmt.

Direkt nach einem Systemstart verfügt mein Hannsi noch über gerade mal 5MB freien Arbeitsspeicher. Ich kann mir kaum vorstellen, dass man mit Compcache gute Ergebnisse erzielen kann, weil man die Größe seines normal nutzbaren Arbeitsspeichers durch die Compcache-Partition weiter verkleinert. Ich lasse mich allerdings auch gerne eines besseren belehren.

Soweit ich das mit Compcache verstanden habe macht es ganau das gegenteil.
Google suche:
Compcache ist im Grunde eine virtuelle Swap-Partition im RAM. Statt auf die SD-Karte ausgelagert zu werden, werden die Daten innerhalb des Compcache-Swap komprimiert. Danach liegen sie zwar immer noch im RAM, haben aber nur noch einen Bruchteil der eigentlichen Größe. Die Idee dahinter ist, dass es auch mit Komprimierung noch effizienter ist, die Dateien im schnellen RAM zu halten als unkomprimiert von der vergleichsweise lahmen SD-Karte zu lesen.
Da nicht alle Daten im RAM komprimiert werden können unterstützt Compcache außerdem eine sog. Backing-Swap. Dabei werden Daten, die nicht komprimiert werden können, doch auf eine Swap-Partition auf der SD-Karte ausgelagert. (Compcache mit Swapfile ist buggy und funktioniert nicht.)

Ich würde ja gerne herausfinden wie das funktioniert, kenne mich aber ganz wenig mit android aus. Hatte soger einen Linuxkurs, wo ich eine Zertifizierung machen konnte. Aber da habe ich leider, leider geschlafen!:sad:
 
PatrickFries schrieb:
Also bei mir passiert es auch dann, wenn ich die SWAP-Partition gar nicht über swapon aktiviert habe. Mir ist gerade aufgefallen, dass die Kernel-Konfiguration des aktuellsten AB-Kernel ein wenig anders ist als die, die er im Quelltext-Repository hinterlegt hat. Ich kompiliere den Kernel gerade mal mit der anderen Kernel-Konfiguration neu. Vielleicht wäre der Käse damit ja schon gegessen. Ich melde mich dann wieder.

Kurze Zwischenmeldung: Das hat leider auch nichts gebracht. Das Hannsi wacht immer noch nicht aus dem Standby auf.
 
SHORTY-NR1 schrieb:
Compcache ist im Grunde eine virtuelle Swap-Partition im RAM.

Aber wo soll man denn bei gerade mal 5MB freiem Arbeitsspeicher noch eine virtuelle SWAP-Partition von angemessener Größe unterbringen?
 
PatrickFries schrieb:
hast du mal beispieslweise mit dem Befehl "free" geprüft, ob der SWAP wirklich aktiv war? Wenn du da jetzt mit autokillern etc. anfängst, dann weiß nicht nicht, was das für Wechselwirkungen hat.

Ja ist aktiv und wird gut genutzt. Ist kein standard appkiller. Der setzt nur die Werte für Android ab wann eine App geschlossen werden soll. Ich glaub die datei dafür heißt minfree. Das App beenden bleibt weiterhin Android selbst überlassen
 
PatrickFries schrieb:
Aber wo soll man denn bei gerade mal 5MB freiem Arbeitsspeicher noch eine virtuelle SWAP-Partition von angemessener Größe unterbringen?

Frage mich wiso du nur 5MB freien Speicher hast und wie dein Hanns überhaupt noch richtig läuft bei 5MB freien Speicher!
Also ich habe wenn ich mein Hanns starte fast 280MB freien Speicher.
Wenn ich damit Surfe usw..., dann habe ich immernoch ca. 80MB frei!
 
Ich werds auch mal testen, ist nun was bei der Supend to Death Problematik rausgekommen? Hast du sicher die sources von dem Kernel genommen, der vorher funktionierte?


Ihr könnt übrigens ein swapfile wie folgt anlegen

128MB file mit dd erstellen (für eure gewünschte grösse einfach den count wert entsprechend ändern):

dd if=/dev/zero of=swapfile bs=1m count=128

die datei wird hier im aktuellen Verzeichnis erstellt , man kann den wünschten Pfad natürlich auch im Stil von of=/pfad/zum/swapfile angeben.

die Datei zu einem swapfile machen:

mkswap swapfile

swap aktivieren:

swapon swapfile

Kontrolle mit :

free
oder auch:
cat /proc/meminfo
 
SHORTY-NR1 schrieb:
Soweit ich das mit Compcache verstanden habe macht es ganau das gegenteil.
Google suche:
Compcache ist im Grunde eine virtuelle Swap-Partition im RAM. Statt auf die SD-Karte ausgelagert zu werden, werden die Daten innerhalb des Compcache-Swap komprimiert. Danach liegen sie zwar immer noch im RAM, haben aber nur noch einen Bruchteil der eigentlichen Größe. Die Idee dahinter ist, dass es auch mit Komprimierung noch effizienter ist, die Dateien im schnellen RAM zu halten als unkomprimiert von der vergleichsweise lahmen SD-Karte zu lesen.
Da nicht alle Daten im RAM komprimiert werden können unterstützt Compcache außerdem eine sog. Backing-Swap. Dabei werden Daten, die nicht komprimiert werden können, doch auf eine Swap-Partition auf der SD-Karte ausgelagert. (Compcache mit Swapfile ist buggy und funktioniert nicht.)

Ich würde ja gerne herausfinden wie das funktioniert, kenne mich aber ganz wenig mit android aus. Hatte soger einen Linuxkurs, wo ich eine Zertifizierung machen konnte. Aber da habe ich leider, leider geschlafen!:sad:

wie ich schon geschrieben habe...
Das ist Comprimierter Cache. Der muss erst dekomprimiert werden, damit die Dateien darin ausführbar sind, aber das geht schneller als von der SD Karte, da die Daten im Ram sind.
Darum bringt das auch nur was, wenn da Daten drin sind, die nur selten verwendet werden.
 
muhviehstarr schrieb:
Ich werds auch mal testen, ist nun was bei der Supend to Death Problematik rausgekommen? Hast du sicher die sources von dem Kernel genommen, der vorher funktionierte?

Ja, genau. Es sei denn, AB73 hat nicht alles in sein Quelltext-Repository commitet. Aber das letzte Commit stammt vom dem Tag, an dem er selbst die aktuellste Kernel-Version veröffentlicht hat. Daher bin ich im Moment auch ein wenig Ratlos.

Hab aber gerade noch bissel was ausprobiert und im Kernel einfach mal die Unterstützung für "Suspend to RAM und Sleep" und "Wake lock" deaktiviert. Danach funktioniert das Aufwecken wunderbar (wahrscheinlich weil gar nicht geschlafen wird ;)), allerdings geht jetzt auf einmal das WLAN nicht mehr. Ich mache noch ein paar Versuche, bin aber nicht besonders zuversichtlich, dass ich da heute noch eine Lösung finden werde.
 
Zuletzt bearbeitet:
SHORTY-NR1 schrieb:
Frage mich wiso du nur 5MB freien Speicher hast und wie dein Hanns überhaupt noch richtig läuft bei 5MB freien Speicher!
Also ich habe wenn ich mein Hanns starte fast 280MB freien Speicher.
Wenn ich damit Surfe usw..., dann habe ich immernoch ca. 80MB frei!

Also ich richte mich da nach der Ausgabe des "free"-Befehls. Der zeigt bei mir folgendes:
Code:
-sh-4.1# free
              total         used         free       shared      buffers
  Mem:       446748       443340         3408            0        23532
 Swap:       125440         1456       123984
Total:       572188       444796       127392

Also nach kurzem Betrieb so um die 3MB freien Arbeitsspeicher. Wenn ich über die Klicki gehe, also Einstellungen -> Anwendungen -> Aktive Dienste, dann zeigt er mir auch 170MB freien Speicher.

Wenn die 170MB aber tatsächlich stimmen sollten, dann frage ich mich, warum Android bei so viel freiem Arbeitsspeicher Anwendungen dermaßen schnell aus dem Arbeitsspeicher kegelt. Da kann doch irgendwie was nicht stimmen. Jetzt ist halt die Frage, ob "free" Recht hat oder die Klicki.
 
Ungenutzter RAM wird wohl wie unter Linux auch als Buffer genutzt. Was sagt z.b. der advanced task killer in Sachen free mem

oder auch cat /proc/meminfo
 
PatrickFries schrieb:
Ja, genau. Es sei denn, AB73 hat nicht alles in sein Quelltext-Repository commitet. Aber das letzte Commit stammt vom dem Tag, an dem er selbst die aktuellste Kernel-Version veröffentlicht hat. Daher bin ich im Moment auch ein wenig Ratlos.

Hab aber gerade noch bissel was ausprobiert und im Kernel einfach mal die Unterstützung für "Suspend to RAM und Sleep" und "Wake lock" deaktiviert. Danach funktioniert das Aufwecken wunderbar (wahrscheinlich weil gar nicht geschlafen wird ;)), allerdings geht jetzt auf einmal das WLAN nicht mehr. Ich mache noch ein paar Versuche, bin aber nicht besonders zuversichtlich, dass ich da heute noch eine Lösung finden werde.

:-(
 
PatrickFries schrieb:
Also ich richte mich da nach der Ausgabe des "free"-Befehls. Der zeigt bei mir folgendes:
Code:
-sh-4.1# free
              total         used         free       shared      buffers
  Mem:       446748       443340         3408            0        23532
 Swap:       125440         1456       123984
Total:       572188       444796       127392

Also nach kurzem Betrieb so um die 3MB freien Arbeitsspeicher. Wenn ich über die Klicki gehe, also Einstellungen -> Anwendungen -> Aktive Dienste, dann zeigt er mir auch 170MB freien Speicher.

Wenn die 170MB aber tatsächlich stimmen sollten, dann frage ich mich, warum Android bei so viel freiem Arbeitsspeicher Anwendungen dermaßen schnell aus dem Arbeitsspeicher kegelt. Da kann doch irgendwie was nicht stimmen. Jetzt ist halt die Frage, ob "free" Recht hat oder die Klicki.

Tatsächlich, mein free zeigt mir auch etwas anderes an als mein Klick (schönes Wort Klick).

Free 90,108MB und Klick 205MB. Allerding habe ich auch neu geflasht.
Eine andere App "android Assistant" zeigt mir auch nur 176MB frei an.

Jetzt bing ich ganz verwirrt. Was stimmt den jetz nu?
 
Manche apps zählen den cache als freien speicher mit, andere nicht.

So ich bin jetzt zurück zum alten Kernel ohne swap, da sleep of death ja noch schlimmer ist als sich schließende apps.
Aber ich halte mich natürlich bereit für einen neuen Kernel!
 
Ich melde mich mal:

Ich hatte jetzt auch zum ersten Mal Sleep of Death, mit original AB73 kernel, ich hatte nur Dolphin HD installiert.

Mir ist folgendes aufgefallen:
Ich hab den FLugmodus an.
Wenn ich einmal auf den On Button drücke, geht die WLAN LED an (nach ca. 1 sek.), der Bildschirm nicht. Ich drücke ein zweites Mal, der Bildschirm geht an.

Könnt Ihr damit euer Problem lösen?
 
Mit dem original kann ich deine vorgehensweise mit 2x klicken bestätigen. Auf diesem kernel hier bleibt der bildschirm definitiv schwarz.
 
marcero schrieb:
Mit dem original kann ich deine vorgehensweise mit 2x klicken bestätigen. Auf diesem kernel hier bleibt der bildschirm definitiv schwarz.

So gestaltet es sich leider auch bei mir. Ich habe gestern noch irgendwo gelesen, dass man bei manchen Kernel erst mal den Lauter- oder Leiser-Taster gedrückt hat und erst dann den Ein-Taster. Beim ersten Versuch hat das auch tatsächlich bei mir funktioniert. Danach allerdings leider nicht mehr...

Ich werde die Woche über wahrscheinlich wenig Zeit haben um der Sache weiter nachzugehen. Allerdings will ich die Sache auf jeden Fall zu Ende bringen, weil mir das Hannsi mit aktivierten SWAP deutlich besser gefallen hat. Es wird wohl aufgrund meiner doch ehr beschränkten Kenntnisse nur ein wenig dauern.

Wenn hier im Forum niemand mehr einen zielführenden Hinweis für mich hat, würde ich versuchen, über den SlateDroid-Thread zum AB-Kernel an Hilfe zu gelangen. AB73 hatte mir da zwar nicht geantwortet, aber jemand anderes der wohl auch bissel den Plan zu haben scheint. Vielleicht hab ich ja Glück und der gibt mir bissel Anfängerunterricht ;)

Falls hier dennoch alle Stricke reißen und ich es nicht auf die Reihe bekomme, dann warte ich auf das Erscheinen der Hannsi-Nicht-Alpha-Version von VegaComb 3.2 (https://www.android-hilfe.de/forum/custom-roms-fuer-hannspree-hannspad-sn10t1.482/vegacomb-3-2-alpha-android-3-2-alte-version.147907.html) und versuche mich an deren Kernel. Vielleicht ist der ja nicht so störrisch ;)
 
Hallo PatrickFries,

hab deinen Kernel mal in den Kernel-Thread mit aufgenommen.

Wenn ich wieder etwas mehr Zeit habe, werde ich mal mit ihm rumspielen ;)

Wünsche dir viel Erfolg.
 
Mano ich würde mich gern bei dem Projekt mit einbringen - bin aber leider zur zeit beruflich und privat bis zum Anschlag eingespannt... :-(
Schaffe es gerade noch eben so ein bischen die Beiträge mit zu verfolgen, mehr ist zur zeit nicht drin... :'(

von (m)einem I9000
powered by Darky's ROM
10.2 extrem Edition ;-P
 
  • Danke
Reaktionen: PatrickFries und Temur

Ähnliche Themen

R
  • rechnerzuhause
2
Antworten
22
Aufrufe
10.200
red-orb
red-orb
heinerl
Antworten
132
Aufrufe
31.980
rotation
rotation
M
  • masterase
Antworten
1
Aufrufe
1.208
heikonet
heikonet
Zurück
Oben Unten