Honeycomb Optimierungen fürs Hannspad

mikaole schrieb:

Bitte schön:

$ export PATH=/data/local/bin:$PATH
$ cat /sys/module/lowmemorykiller/parameters/minfree
20480,25600,20480,20480,20480,25600
$

Unter Gtab und 04er Kernel, falls das interessant ist

Zum Vergrößern anklicken....

Welch total sinnfreie Einstellungen für die minfree Settings...

Will mich mit dem script auch näher beschäftigen. Was sagen denn diese Werte aus?

Ich finde das skript eigentlich super, bloß der Bug, dass es mit der Zeit langsam wird, nervt halt.

Aber mit etwas tweaking müsste das doch zu beheben sein.

marcero schrieb:

Welch total sinnfreie Einstellungen für die minfree Settings...

Zum Vergrößern anklicken....

keine Ahnung, kenne mich mit den Einstellungen nicht aus. hatte aber noch nie einen Freeze, kein SOD und auch sonst überhaupt keine Probleme, deshalb ziemlich wurscht für mich.

echo 1536,3072,5632,6144,7168,8192 > /sys/module/lowmemorykiller/parameters/minfree;

Zum Vergrößern anklicken....

sind jene Werte, ab denen Prozesse gekillt werden, wenn der freie RAM unter diese Grenze fällt. Die Werte sind in Pages, mit 4096 umzurechnen.

echo 0,3,5,7,14,15 > /sys/module/lowmemorykiller/parameters/adj;

Zum Vergrößern anklicken....

Linux und auch Android, teilen den Prozessen verschiedene Prioritäten zu. Wenn der freie Ram unter die oben genannte Grenze fällt, werden alle Prozesse mit einer Priorität größer als die jeweilige Zahl (z.B. unter 8192 werden alle Prozesse mit 15 oder größer) gekillt.


Insofern:
Ein Script halte ich auf Honeycomb für absolut notwendig.
Nich so viel, wie im ersten Post, aber doch einiges.
Ich habe derzeit das ein verändertes Script wie im ersten Posting ohne die Battery Control.

ah ok, aber ich hatte egal welches script ich drauf hatte immer das Gefühl, das mein Pad nicht mehr so rund läuft, deshalb habe ich die scripts wieder gelöscht.

Kannst gerne einmal dein script posten, dann teste ich auch das einmal aus.

Ich lese hier schon einige Zeit mit. Ein dickes Lob von mir an all die hart arbeitenden Leute hier.

Ansich ist die Idee für das Script nicht schlecht. Nur fällt mir die Logik dahinter etwas schwer.
Honeycomb ist auf 1gb Ram ausgelegt, soweit klar.
Leider haben wir nur 512Mb Ram.

Was ich nicht verstehe ist, wieso es Sinn machen soll die Grenzen zu ändern ab denen Android bestimmte Prozesse killt weil zu wenig Ram verfügbar ist.
Diese Mindestgrenzen die Android einhalten will um eine bestimmte Größe Ram frei zu halten hat dann doch garnichts damit zu tun wieviel RAM absolut zur Verfügung steht.
Die Grenzen basieren, nach meiner Logik, auf dem Bedarf der Programme die der User möglicherweise in Zukunft starten will. Android sorgt also vor, dass immer genug Ram für ein zu startendes Programm verfügbar ist, aber nicht zuviel Ram leer liegt den laufende Prozesse gut gebrauchen können.

Ich benutze zur Zeit das aktuellste Script ohne Runtertakten im Standby da ich sowieso SetCPU laufen habe was diese Arbeit übernimmt.
Allerdings stelle ich mir die Frage ob das die anderen hier auch so tun. Was wäre wenn SetCPU ein Profil für Standby aktiviert hat, aber trotzdem das Runtertakten noch im Script steht? Besteht da nicht die Gefahr, dass sich SetCPU und das Script gegenseitig "stören"?

Bis jetzt habe ich das Problem, das alles erstmal super läuft bis irgendwann Programme laggen. Als DAU denke ich mir dann der Ram ist zugemüllt.
Ich habe deshalb mal die TweakRAM Werte vergrößert. Aber wem sag ich das. Mit diesen Werten spielen hier ja alle herum.

Wieso enthält das Script eigentlich die Absicherung der Akku-Temperatur? Mein Honeycomb zeigt mir immer 30°C an. Da ändert sich nichts. Deshalb ging ich immer davon aus, dass diese Anzeige einfach nicht funktioniert. Bekommt das Script die Werte woanders her?

Habe jetzt den script auch ein guten Tag drauf und bin weder entäuscht noch begeistert. Wie jedes Script bei Langzeitbenutzung fällt auf das nicht mehr alles so rund läuft wie ohne script. Der Vorteil ist das ich mehr Tabs gleichzeitg öffnen kann in Opera und das ich nebenbei Musik/Radio hören kann. Ohne script kann ich nur eine begrenzte Anzahl Tabs öffnen (besonders bei Seiten mit vielen Flash Inhalten) oder nur beschränktes Multitasking habe. Pad ist nun übertaktet auf 1.4Ghz mit script und bin zufriedener als mit den vorherigen scripts.

cantax schrieb:

Was ich nicht verstehe ist, wieso es Sinn machen soll die Grenzen zu ändern ab denen Android bestimmte Prozesse killt weil zu wenig Ram verfügbar ist.
Diese Mindestgrenzen die Android einhalten will um eine bestimmte Größe Ram frei zu halten hat dann doch garnichts damit zu tun wieviel RAM absolut zur Verfügung steht.
Die Grenzen basieren, nach meiner Logik, auf dem Bedarf der Programme die der User möglicherweise in Zukunft starten will. Android sorgt also vor, dass immer genug Ram für ein zu startendes Programm verfügbar ist, aber nicht zuviel Ram leer liegt den laufende Prozesse gut gebrauchen können.

Zum Vergrößern anklicken....

Soweit ich weiß, versucht die Android-Speicherverwaltung (anders z.B. als Windows), soviel Hauptspeicher wie möglich mit schon mal gestarteten Anwendungen zu belegen, damit diese bei Bedarf schnell wieder zur Verfügung stehen. Wenn man ein Programm startet und danach zum Homescreen zurückkehrt, wird dieses Programm nicht beendet, sondern läuft im Hintergrund weiter. Das hat auch damit zu tun, daß jede Anwendung in einem eigenen Prozess und in einer eigenen virtuellen Umgebung läuft, der Start so einer Anwendung dauert somit wohl etwas länger, als wenn die Anwendung direkt im Betriebssystem ausgeführt würde. Wenn also der Zeitpunkt, an dem Anwendungen mangels freiem Speicher beendet werden müssen, weil eine zusätzliche gestartet wird, möglichst weit hinausgeschoben werden kann, kann man auch schneller wieder auf diese Anwendungen zurückgreifen, da sie nicht neu geladen werden müssen. Durch die Verringerung der "Kill-Speichergrenze" versucht das Script so, mehr Platz für Anwendungen zu schaffen.

Alles natürlich imho.

Daß das Script je nach Anwender unterschiedliche Auswirkungen hat, hat dann sicher damit zu tun, welche Programme individuell benutzt werden.

... und da die Grundeinstellungen für 1024 MB RAM optimiert sind, müssen die für unseren etwas problematischen Fall (512 MB) angepasst werden.

Also ich sehe großes Potential in diesem Skript, muss man halt schaun welcher Teil noch Probleme bereitet.

Löst sich das RAM Problem nicht mit Freigabe der ics Codes? Da wird es sicher nicht anders ablaufen mit der speicherverwaltung, es gibt aber definitiv Geräte die kein gig RAM haben und auf denen ics trotzdem läuft. Hc Geräte haben meines Wissens alle 1 gig RAM, deswegen ja auch diese Optimierung seitens Google. Also heißt es doch nur noch ein wenig Geduld haben

Wer mit Scripten spielen möchte kann dieses versuchen:
xda-developers - View Single Post - [Script][U9 RC3.2!] -=V6 SuperCharger=- Die-Hard BulletProof HTK Launchers, 3G & KAK!

Die neueste Datei, 6.3 herunterladen, das .pdf löschen (warum ist das da?) und aufs Hannsi kopieren.

Im Script Manager die Datei auswählen und als Root ausführen (NICHT als Boot). Dann den Anweisungen folgen und Erwünschtes auswählen.

Ihr müsst anschließend die S99... Datei im Ordner /system/etc/init.d/ im Script Manager bei Boot laufen lassen, da wir keine Init.d Autostarts haben.

Also ics wird denke ich noch ewig dauern. Und das Kernel Problem beginnt dann von neuem denke ich mal. Wir sollten uns erstmal auf HC konzentrieren.

@heinerl: Entschuldige wenn ich nochmal nachhake. Du bist nicht auf den Punkt eingegangen den ich beschrieben habe.
Deine Erklärung der Speicherverwaltung unter Android leuchtet mir ein. Nur hat Honeycomb doch diese Mindestwerte ab der Prozesse gekillt werden schon drin die dann per Script manipuliert werden.

ABER: Was hat das dann mit der absoluten Größe des RAMs zu tun? Android will den Prozessen soviel RAM geben wie möglich und nur eine Reserve halten für zukünftige Programmstarts oder Bedarf durch laufende Prozesse.

Klar kann man das Manipulieren damit unsere 512Mb Geräte weniger RAM in Reserve halten. Aber das hat NICHTS mit der absoluten Größe des RAMs zu tun.

Alles was wir tun ist die letzte Reserve im RAM zu verkleinern. Dass das dann aber zu Problemen führen kann ist logisch weil die Android Entwickler die Minimalgrenzen nicht ohne Grund so gesetzt haben wie sie nunmal sind.

Ich hoffe du verstehst mein Problem. Würden wir das Script bei einem Gerät mit 1gb RAM anwenden würde es auch was bringen. Man könnte dann halt zB 10 offene Programme im Ram halten statt nur zB 8. Auf dem 512MB Gerät sind es dann 5 offene Programme statt der sonst nur möglichen 4.

Durch das frühe freischaufeln des RAMs wird zB der Launcher häufig beendet. Dadurch kommt es zu nervigen Verzögerungen im Arbeitsablauf. Wenn man das Skript verwendet sieht man ja auch was es bringt. Läuft alles deutlich flüssiger. Leider spinnt dann die Speicherverwaltung ab ner gewissen Zeit, das sollten wir halt noch verbessern.

Ich hab mal gelesen dass HC normalerweise 100MB RM frei hält. Sind bei 1024 MB nicht soo viel, bei 300 MB Ram ist das schon heftig.


Mal eine Frage: Woher weiss ich welche Prozesse mit welcher Priorität laufen? Vielleicht sind manche apps einfach unsauber programmiert und stören somit die Speicherverwaltung?

alex_fost schrieb:

Ich hab mal gelesen dass HC normalerweise 100MB RM frei hält. Sind bei 1024 MB nicht soo viel, bei 300 MB Ram ist das schon heftig.

Zum Vergrößern anklicken....

Eben genau das ist der Punkt. Um problemlos zu laufen braucht HC 100MB freien RAM. Ob das 100MB von 1gb sind oder 100mb von 512mb ist dabei doch vollkommen egal.
Klar läuft es erstmal mit dem script besser. Wenn ihr die Werte noch weiter runterschraubt wird es sogar noch besser laufen. Aber dann wird es auch früher zu Problemen kommen.

cantax schrieb:

Um problemlos zu laufen braucht HC 100MB freien RAM.

Zum Vergrößern anklicken....

Nein, eben nicht, das ist nur die Voreinstellung bei den Honeycomb-Roms, weil es da RAM im Überfluss gibt. Android braucht eigentlich gar keinen freien Speicher. Da werden sogar Dummy-Prozesse gestartet, um möglichst viel freien Speicher "aufzubrauchen". Wenn kein freier Speicher mehr zur Verfügung steht, um neue Anwendungen zu starten, werden automatisch Anwendungen beendet, die im Hintergrund laufen.

rotation schrieb:

Wer mit Scripten spielen möchte kann dieses versuchen:
xda-developers - View Single Post - [Script][U9 RC3.2!] -=V6 SuperCharger=- Die-Hard BulletProof HTK Launchers, 3G & KAK!

Zum Vergrößern anklicken....

Und, bringt das was?

keine Ahnung, wird von vielen Seiten recht hoch gelobt, ich bin grad am testen....

Wie schaut es mit dem VMHeapsize aus habe gesehen das bei Flash 10 Easy der VM Heap auf 256m eingestellt ist sollten nicht maximal 48m reichen, da bei mehr es doch zu Abstürzen kommt, oder ist bei Honeycomb der Wert grundsätzlich höher!?

MFG

Wolverine_DH

Eine Frage hätte ich noch zum Script, da ich gerade selber am basteln und experimentieren bin:

# Tweaks RAM"
echo 1536,3072,5632,6144,7168,8192 > /sys/module/lowmemorykiller/parameters/minfree;
echo 0,3,5,7,14,15 > /sys/module/lowmemorykiller/parameters/adj;
echo 0 > /sys/module/lowmemorykiller/parameters/debug_level;
echo 64 > /sys/module/lowmemorykiller/parameters/cost;


# NEVER kill the launcher, speedup Home return but less free memory
echo -17 > /proc/`pidof com.android.launcher`/oom_adj;


1. Frage: Die erste Zeile ist klar, da werden die RAM Untergrenzen zum killen bestimmter Prozesse definiert. Was wird aber in den Folgezeilen gemacht? warum werden die adj Parameter noch geändert?

2. Frage: Ich habe in meinem Script vorerst nur die erste Zeile mit den RAM Untergrenzen und die Zeile mit dem Launcher drin. Trotzdem kommt es teilweise zur beendigung des Launchers, auch bei wenig RAM Belastung. Liegt das daran, dass ich die adj-Parameter (2. Zeile) nicht anpasse? Und reicht es nicht den oom_adj Parameter auf 0 zu setzen? Warum wird der auf -17 gesetzt?