[Kernel] Franco Kernel V10 (04.04.2012)

Es gibt einen weiteren Kernelentwickler für's Note.
Franco.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 04.04.2012 V10
http://www.pocketpc.ch/galaxy-note-r...ml#post1375066
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 11.03.2012 V9
http://www.pocketpc.ch/galaxy-note-r...ml#post1353083
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 01.03.2012 V8
http://www.pocketpc.ch/galaxy-note-r...ml#post1345803
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 26.02.2012 V7
http://www.pocketpc.ch/galaxy-note-r...ml#post1342202
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 18.02.2012 V6
http://www.pocketpc.ch/galaxy-note-r...ml#post1336581
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Update 17.02.2012 V5
http://www.pocketpc.ch/galaxy-note-r...ml#post1335862
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 14.02.2012 V4
http://www.pocketpc.ch/galaxy-note-r...ml#post1333820
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 14.02.2012 V3.1
http://www.pocketpc.ch/galaxy-note-r...ml#post1333565
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Update 12.02.2012 V2
http://www.pocketpc.ch/galaxy-note-r...ml#post1332434
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

XDA Thread:
http://forum.xda-developers.com/show....php?t=1491428


Er macht dies schon länger, ist XDA anerkannter Entwickler und legt vor allem Wert auf Batterieschonung, bei maximal möglicher Performance (wer macht das nicht )

Er hat den ondemand Governor getweakt, sowie den cfq Scheduler und meint, dass entgegen den Aussagen anderer Kerneldeveloper, ein getweakter CFQ besser sei.

Nun, schauen wir mal

Inhalte:

• * Initramfs with the usual stuff (root, CWM support, recovery etc)
• * Partitions properly mounted in the ramdisk to take the most out from the device
• * VM values tweaked up for maximum performance/battery
• * Ondemand governor properly tweaked - features 10k sampling rate for more fine grained samplings
• * CPU frequency transition latency decreased to 40k instead of stock 100k
• * I/O boosted - I feel this is the most important setting in the Android kernels
• * CFQ I/O scheduler by default - most of the Android kernel devs choose to work with deadline or other schedulers, but after deep testing a proper tweaked CFQ for flash devices proved me as the most reliable choice
• * CFS task scheduler properly tweaked for the best multi-tasking experience
• * CFS Autogroup added
• * TCP Veno congestion scheduler by default as its more suitable for this kind of devices
• * Kernel stripped of debug shit - the only debugs that stayed were: logcat, printk and kallysms (for Voodoo Louder support)
• * Hotplug fixed with arighi patches
• * Patched up to 2.6.35.13 from the mainline kernel channel
• * CRC32 library that is used by a lot of internal kernel mechanics completely patched up to the latest versions
• * Compiled with Tree RCU Fast No Hz for further battery savings
• * The usual Franco's magic
• * Lots lots more that I will remember later and add it back here...

Download:
http://minooch.com/franciscofranco/G....Kernel-10.zip

Wer will, kann nun auch das Franko Kernel App kaufen:
https://market.android.com/details?i...co.kernel.note

Achtung, man brauch vorher ein "sauberes Gerät".
Hatte man vorher andere Kernel's, Thunderbolt Scripts oder "zeugs" aus Custom ROM's, ... weg damit.

1. Zuerst eventuelle Profile von Set CPU, Voltage Control oder ... deaktivieren, damit sie beim Boot nicht geladen werden
2. Kernel Downloaden und auf die SD Karte kopieren
3. jBroid_Kernel_Cleaning_Script laden, auf die SD Karte kopieren und im Recovery (nicht über das CWM App) Flashen
4. Im Recovery bleiben und den Kernel Flashen (install zip from...)
5. Reboot und fertig.

Ein Test Wert??
Ich fahr gerade mit AbNo v3.7 ganz gut ...
hast ma Blick geworfen??

(Moin Großer )

Mh ja, bin aber wieder zurück.
Das Gerät geht in den Deepsleep, aber nicht Sleep, sondern Koma.
Benchmarks sind sehr gut, smoothness auch, aber ... er muss noch ein wenig dran feilen.

Back to Abyss 3.7

Wir geben ihm mal die Zeit

Danke!! (sagt auch mein Note )

Schalom der Reddy

Ja, es scheint aber ein sehr Erfahrener Kerneldeveloper zu sein.
Wir können als gespannt sein.

wie ein Flitzebogen

lol, Koma ist gut! Hoffentlich ist Dein SGN danach kein Apalliker z.B. aufgrund einer O²-Insuff.
Danke für den Hinweis, weil dann machen wir da mal nen großen Bogen drum.

o.k. Problem gelöst.
Man brauch ein sauberes Gerät.
Ich habe nun vorher das jBroid_Kernel_Cleaning_Script drüberlaufen lassen und siehe da.
Everything works fine.

Auf zum Langzeittest.

Zitat von spline

* TCP Veno congestion scheduler by default as its more suitable for this kind of devices

Wow... das erste mal, dass ich sehe, dass sich ein Kernel-Dev sogar dem Thema TCP congestion annimmt. Entweder weiss er wirklich, was er tut oder ist ein grenzenloser Übertreiber. Mal antesten. Aber auf jeden fall: Fett...!

Hatte trotzdem wieder koma statt deepsleep.
Schade.

Gibt ne V2. Habe die wieder runtergeworfen, laut XDA sind permanent beide Cores aktiv.

Also ich lese seit der V2 nur Lobgesang.
Das mit den 2 Cores ist kein Bug, sondern ein Feature.

Changelog:
#2

• * Conservative set as the default governor - gave it 10k sampling rate like I did on Ondemand and gave it a 80 up_threshold, a bit lower than the stock value. This will make the governor scale up a bit more often, making the system a lot snappier while maintaining a good battery balance
• * Added SLQB memory allocator - I usually tend to use SLUB, but I decided to give this one a try this time and it proved to be a great choice
• * Dynamic Hotplug disabled - we want the system to have both cores always enabled. This means two things, means it will help a lot for the race-to-idle (the fast we go into idle the more battery we can save), and it means the amount of overhead that was created during onlining/offlining cpu1 is gone since hotplug is a very costly process to the system
• * Power Management patches from the mainline kernel
• * EXT4 driver patched up a little bit
• * EXT4 write performance regression fixed (regression is when a newer introduced code fucks up, unintentionally, some other code, in this case the regression was fixed)
• * Lowmemorykiller driver patched up for a better memory management
• * Sleep of death issue should be fixed
• * Introduced VMAP_AREA_CACHE - for more information visit this old commit from me (commit)

Download:
http://minooch.com/franciscofranco/G...o.Kernel-2.zip

@Spline bitte um ne verständlich leichte Erklärung was das bringt, wenn Beide Cores aktiv sind?

Das sagt der Translator

Dynamische Hotplug deaktiviert - wir wollen das System zu haben, beide Kerne immer aktiviert. Das bedeutet zwei Dinge, bedeutet, es wird viel für die Race-to-Leerlauf (die schnell wir gehen in den Leerlauf der Batterie mehr wir sparen können) helfen, und es bedeutet, den Anteil des Overheads, die während Onlining / Offlining CPU1 ist weg erstellt wurde seit hotplug ist ein sehr kostspieliger Prozess, um das System

Das das ein Feature ist, war mir schon klar. Aber ich als LAie denke mir, dass 2 dauernd laufende Cores doch vermutlich auch mehr Energie brauchen.

Ich bin auch nur Laie, verstehe es aber so, dass es mehr Strom kostet, wenn oft deaktiviert und wieder aktiviert wird und auch der sonst nur eine Core nicht mehr soviel Overhead erleiden muss.

Nun, schauen wir mal. Auf jeden Fall ist der Kernel verdammt fix.

Das iss ma keine Google Übersetzung ... Danke

Die Theorie, die geäussert wurde und jetzt in Praxis erprobt wird (die User sind - deklariert - Testkaninchen), lautet so:
der zusätzliche Verwaltungs- und Benachrichtigungsaufwand (Overhead), der durch das Managen der Cores anfällt, ist unter bestimmten Szenarien unvorteilhaft. Dies, da, so die Annahme, anteilsmässig mehr Leistung im Overhead verschwindet als effektiv hinten raus kommt. D.h. der 2. Core wird aktiviert, der Batteriekonsum wird x-fach erhöht, die zusätzliche Leistungsausbeute ist aber nur x/y mal grösser, also weniger viel mal grösser, als mehr viel mal Batterie gezapft wird, also relativ gesehen. Die bekloppte Formulierung ist übrigens absichtlich so gewählt
Um den Gedanken hinter der Sache nun zu vollenden: lässt man dauerhaft beide Cores aktiviert, zieht dies grundsätzlich mehr von der Batterie, ist klar. Aber, und dies gilt es als Testkaninchen zu erproben, ist durch den fehlenden Overhead - dynamisches (de-)aktivieren der Cores ist ja aus - die Leistungsausbeute relativ gesehen grösser als es der Batteriekonsum ist. Denn, und das ist das ominöse race-to-idle, je schneller das System eine anfallende Aufgabe erledigt hat, desto eher kann es in einen stromsparenden Modus fallen. Frage ist, ob das Volle-Pulle-Abarbeiten und früher fertig sein effektiv unter dem Strich weniger Stromverbrauch bedeutet pro Zeiteinheit wie das halbherzige Abarbeiten unter weniger Leistungsaufnahme, dafür während längerer Zeit. Und hier schliesst sich der Kreis, den unter bestimmten Szenarien (siehe oben ) stimmt diese Annahme, unter anderen hingegen nicht.

Kurzum: Francos Kernel versucht, anhand von optimierten Governors und Schedulern (I/O wie auch Taskscheduling), deaktiviertem Hotplugging mit race-to-idle und reduziertem Overhead, (gefühlt) gleichbleibende Leistung bei weniger Batterieverbrauch oder aber gleichbleibender Batterieverbrauch bei (gefühlt) besserer Leistung zu erreichen und dabei gleichzeitig gewisse Theorien in Bezug auf race-to-idle und hotplugging overhead zu untersuchen. Ich bin dabei mit an Bord, bis jetzt mit V1, ich teste V2 morgen dann. Bis jetzt keinerlei Beschwerden, nicht im Geringsten irgendwelche Hickser.

Du kannst es einfach besser Erklären.

Das ist durchaus auch für einen Laien verständlich, mit bissel rein denken. Danke @schago!!

Ich teste gerade die v2 ... werde aber sicher nur "gefühlt" Änderungen merken,
als Laien-Test-Kaninchen

Schalom der Reddy