INFO: Es scheint so, dass Xiaomi für Miui einen eigenen Kernel entwickelt, das heisst also, dass die Custom Stock Kernel Probleme machen könnten. Der Siyah hat bei mir bis jetzt keine Probleme gemacht, alle anderen müsst ihr ausprobieren. Wenn ihr im Boot Loop landet wisst ihr es.
Guten Tag liebe Forengemeinde,
Ich möchte mich hier dem Thema Kernel widmen. Was ist ein Kernel? Ein Kernel ist das Bindeglied zwischen Hardware und Software. Wenn also der Kernel "schmutzig" ist, also falsche oder unnötige Tweaks und Scripte drin hat, kann es sich negativ auf die Akkulaufzeit auswirken. Es gibt teilweise Kernel Devs, die Hacks einbauen, damit das Tel besser in Benchmarks abschneidet. Da Benchmarks aber nichts über die Alltagsnutzung aussagen, kann man sich denken, welches Geistes Kindes diese Devs sind... 
WICHTIG!!! Wenn ihr einen Custom Kernel drauf habt und Probleme entstehen, schaut bitte zuerst im jeweiligen Kernel Thread, und nennt, wenn ihr hier postet den Kernel den ihr habt, da wir hier sonst sehr schlecht ermitteln können, wo das Problem liegt. Wir möchten ja gerne helfen, anders ist das aber nicht möglich. Danke
Welche Kernel sind für Miui geeignet? Alle Kernel die für Samsung (Stock) Roms geeignet sind, oder Hybriden, also Kernel die auf AOSP/AOKP UND Samsung (Stock) laufen. (Nur Miui V4!!) AOSP/AOKP Kernel sind für Miui nicht geeignet!
Welche Kernel sind das aktuell? (*)
Abyss
Siyah
Dorimanx
Phenomenal
N-E-A-K
Voku
S2Mod Kernel
Der Voku, sowie der Dorimanx basieren auf dem Siyah, sind aber mit Tweaks von anderen Kernel gespickt. Der S2Mod Kernel hat einen Miui-Spezifischen Kernel. Sobald ich mehr weiss, was dieser Miui Kernel von den anderen "Stock" Kernel unterscheidet, werde ich die Infos hier posten!
*Ich versuche es möglichst aktuell zu halten, haut mich aber nicht, wenn mal ein neuer kommt und er ist hier nicht drin 
Muss beim Kernelflash etwas beachtet werden? WICHTIG!!!: Es kann beim Kernelflash immer etwas schief gehen, gerade letztlich wurden ein paar SGS2 durch einen Fehler in der Kernelsource gebrickt!!! Alles geschieht auf eigene Gefahr, seid euch einfach bewusst, dass etwas schief gehen kann! Es ist ratsam, wenn du bereits was am Gov, Sheduler oder der Spannung geändert hast, diese Änderungen rückgängig zu machen, denn sonst kann es sein, dass du nicht weit kommst und das Tel einfriert. In der Regel reicht es den dalvik cache zu wipen. Wer ganz sicher gehen will, flash zuerst das Kernel Cleaning Script von hier: klick und danach den Kernel.
Nun, was bringt ein anderer Kernel? Ein sogn. Custom Kernel kann zu besseren Akkulaufzeiten beitragen, das Touchverhalten, Scrollen und Reaktionszeiten verbessern. Viele Kernel haben ein Touch Recovery, und sind natürlich besser anpassbar was Govenors und Sheduler angeht, können aber auch Probleme (Bugs) mit sich bringen. Wer auf der ganz sicheren Seite sein möchte, der lässt es besser beim Stock.
18 Step CPU Tabelle:
Der Siyah Kernel hat seit einiger Zeit eine neue Frequenztabelle eingeführt, sie so genannten 18 Steps. Das heisst also: 25/50/100/200/300/400/500/600/700/800/900/1000/1100/1200/1300/1400/1500/1600 sind von der CPU ansteuerbar. Die 25 und 50mhz empfinde ich als ziemlich unnötig. Fakt ist, das man bei diesen Steps sehr weit runter kann mit der Spannung, da sie jedoch kaum aktiv sein werden und zu Ruckler oder Freeze auf einigen Geräten führen, halte ich nicht viel von diesen Steps. Probiert es aus und entscheidet selber. Ich habe 100-1200 aktiv. Der ondemand Govenor scheint jedoch weiterhin die "Hauptfrequenzen" 100/200/500/800/1000/1200 am meisten anzusprechen, jenachdem wie dieser eingestellt ist. Das heisst jedoch nicht, dass die anderen Steps nicht genutzt werden, nur weniger.
Ein leidiges Thema in der Kernelszene sind die 100mhz als niedrigsten Takt. Samsung hat Standartmässig 200mhz als Mindesttakt. Fakt ist, dass das Tel beim Musik hören oder im Leerlauf gerne und oft die 100mhz nutzt, wenn man sie freigibt. Fakt ist ebenfalls, dass nicht nur die Spannung (mV) darüber aussagt, wie sparsam eine Frequenz ist, sondern auch die Frequenz an sich. Wenn nun also 100mhz einen Verbrauch von "1" hat, entspricht der Verbrauch von 1200mhz z.B. "12", ohne dass man die Spannung dabei berücksichtigt. Diese kommt noch zusätzlich dazu! Das bedeutet also, dass 100mhz sparsamer sind als 200mhz, auch wenn sie die selbe Spannung (mV) haben! Die Faktoren 1-12 bedeuten allerdings nicht, dass z.B. 200mhz doppelt so viel Strom ziehen wie 100mhz, oder 1200mhz gar das 12 Fache von 100mhz, so einfach ist das nicht. Sie dienen nur als Beispiel. Kommen wir nochmals zurück aufs Musik hören: Ich höre jetzt 2h Musik, und da beim Musik hören 100mhz ausreichen, verbringt das Tel auch die meiste Zeit davon in diesem Bereich. 100mhz haben eine etwas niedrigere Spannung als 200mhz und haben auch den Fator "1". Wenn ich nun also 2h auf 100mhz verbringe statt auf 200mhz, habe ich 2h auf einer etwas niedrigeren Spannung und einem niedrigeren Faktor verbracht. In der Theorie also etwas gespart, wenn vllt. auch nur minimal.
Standartmässig ist bei den meisten Kernel der ondemand Govenor eingestellt. Meistens beinhaltet der ondemand noch die ondemandx oder intellidemand Tweaks (intelligentere Skalierung, bei Bildschirm aus max. Frequenz 500mhz u.a.) Entweder steht das, oder man muss es auf github selber nachschauen. Vorteil von ondemand ist meiner Meinung nach, dass es keine Lags gibt. Der Nachteil ist, dass er manchmal etwas zu schnell zu hoch taktet, und so unnötig Leistung verbraten kann, jenachdem wie der ondemand eingestellt ist. Wer nicht lange experimentieren will, sollte die Einstellungen einfach so lassen wie sie sind, der Kerneldev hat sich schon überlegt, warum die eingestellten Werte Standart sind! Wer eine intelligente Skalierung der Frequenzen haben möchte, benutzt am besten den ondemand Govenor. Was Effizienz angeht, ist der ondemand sehr gut. Ein Beispiel wenn man die 100er Steps beim Siyah aktiv hat, was Standartmässig so eingestellt ist: Ein Prozess braucht 600mhz um effektiv verarbeitet zu werden, der ondemand merkt das und skaliert auf diese Frequenz. Ohne die 100er Steps würde der Govenor warscheinlich auf 800mhz takten, ob der Prozess mit 800mhz nun etwas schneller verarbeitet wäre oder nicht, lassen wir mal aussen vor. Tatsache ist jedoch, dass 800mhz etwas mehr Strom benötigen als 600mhz und zudem einen höheren Faktor haben. In der Theorie also etwas gespart. Es kommt nicht auf einzelne Prozesse an, sondern auf die Gesamtsumme.
lulzactive
Der lulzactive gehört ja zu den interactive basierenden Govenors, die "erahnen" sollen, wann Leistung benötigt wird. Im Unterschied zum ondemand, der Leistung gibt wenn sie gebraucht wird. Wenn man wirklich alle Steps nutzen möchte die die Tabelle zu bieten hat, sind die oben genannten Einstellungen ganz gut. Um etwas mehr Performance, und unnötige Skalierungsvorgänge zu vermeiden, sollte man besser up 2 und down 2 oder gar 3 bei beiden verwenden. Denn wenn Leistung benötigt wird, kann es bei den 1er Schritten zu Verzögerungen und Lags führen. Ein Beispiel: Die CPU taktet auf 500mhz sobald man den Bildschirm berührt, dann öffnet man z.B. den Play Store, der die CPU nun mal dazu bringt auf 1200mhz zu skalieren und meistens auch der zweite Kern anspringt. Wenn man bei den "pump_up:step nun ne "1" drin hat, skaliert die CPU also 7 mal einen Schritt nach Oben. Jenachdem welchen Wert man bei der "up_sample_time" hat, kann es also etwas dauern bis die 1200mhz erreicht werden und daher zu Verzögerungen führen. Wird die "up_sample_time" nun alle 20000 mikrosekunden (20ms) abgefragt, ist die CPU also in ca. 140ms auf 1200mhz. Die Zeit ist jetzt vielleicht kein so grosser Faktor, es kann aber trotzdem zu kleineren Lags, oder "Hakeln" kommen. Viel mehr finde ich diese 7 Schritte an sich unnötig, da die meisten Frequenzen gar nicht wirklich genutzt, sondern durch den User gezwungenermassen durchskaliert werden. Ich habe Tests gemacht mit pump_up 2 und 3, ebenfalls bei pump_down 2 oder 3. Tatsache ist und bleibt, es gibt dann einfach die oft benutzen Frequenzen im Abstand von 2, bzw. 3 Schritten und der Rest bleibt oft unbenutzt. Man schreibt der CPU also ihr Skalierungverhalten vor. Ich fand das lange Zeit super, doch im Moment teste ich den ondemand wieder etwas aus, da ich egal mit welchen Einstellungen vom lulzactive immer wieder kleinere Lags im Store beim scrollen hatte, sowie bei der Aufnahme von Videos in 720p sowie 1080p. Die Videos waren völig unbrauchbar! Mit der up_sample_time von 10000 gab es temporär etwas besserung, aber irgendwann kamen die Lags zurück. Der ondemand hat diese Probleme nicht.
SHED_MC:
SHED_MC gibt es die Einstellung "0" (Samsung default = kein Einfluss) "1" (Der erste Kern wird zuerst belastet, der zweite dann bei höherer Belastung zugeschaltet) und "2" (Beide Kerne werden abwechselnd ab und zugeschalten) Ich habe hier die "1" aktiv, da das abwechselnde zu und abschalten von "2" zu höherem Verbrauch führen kann. Wenn man die Standart Einstellung von Hot Plug verwendet, also weder nur Singelcore oder nur Dualcore, muss man an dieser Einstellung eigendlich nichts verändern, da es das Hot Plug Profil von selbst regelt. Ich habe SHED_MC "1" mal zugeschaltet und mal nicht, und konnte dabei nicht wirklich einen Unterschied im Verhalten des zweiten Kerns erkennen.
Ich will und kann euch keine Tipps geben welchen Kernel ihr nehmen sollt. Probiert sie aus, schaden kanns nicht! Jeder hat seine eigenen Kriterien was ein Kernel bewirken soll. Längere Akkulaufzeit, bessere Performance, besseres Touchverhalten, Dual Boot usw. Lest euch die Kommentare durch was andere User berichten und entscheidet dann. Ich würde pro Kernel sicher mal nen Tag investieren. Ihr solltet halt darauf schauen, dass ihr beim testen immer etwas dasselbe Nutzungsverhalten an den Tag legt, und auch genau drauf schaut wie lange der Bildschirm an war. Vielleicht hat ein Kernel eine Laufdauer von 20h mit 3h Bildschirm an, der nächste hat nur 18h, dafür aber mit 4h 30min Bildschirm an. Das ist sehr wichtig zu beachten!! Ein Beispiel nenne ich jetzt aber doch, der Siyah braucht im Deep Sleep sehr wenig Strom, da kann ihm kaum ein anderer Kernel was, dafür saugt er dann etwas mehr bei Benutzung. Hier gibt es noch einen guten Thread zum Thema Kernel und deren Verbrauch: klick Der OP des Threads nutzt eine AOKP Rom, ihr müsst einfach darauf schauen, dass ihr nur Hybrid Kernel, also Kernel welche unter AOSP/AOKP UND Samsung (Stock) laufen nehmt!! Der Fokus liegt dort also mehr auf AOSP/AOKP, aber es werden auch Hybriden getestet.
Kernel Tools:
Extweaks, Voltage Control, lulzactive, Set Cpu, NSTools, usw.
Diese Tools sind dazu da, spezielle Einstellungen wie mV per Taktfrequenz, Govenor, Sheduler, Hot Plug Modus, Vibrationsintensität, wann der zweite Kern zugeschaltet wird usw. am Kernel vorzunehmen.
Hier noch zwei sehr wichtige Links zum Thema Govenors und Sheduler:
FAQ Govenors u. Sheduler
Tweaks für Govenor, Sheduler u.a.
Da in den oben genannten Links alles zum Thema Gov und Sheduler drin ist, erspare ich mir hier ein copy & paste, von dem ich sowieso kein Fan bin, da ich lieber selber schreibe. Doch besser kann man es gar nicht verfassen, also lass ich das 
Von Overclock halte ich Persönlich gar nichts! Im Alltag machen sich 1400mhz oder 1600mhz nur negativ im Akkuverbrauch bemerkbar. Wer also keine Potenzverlängerung im Benchmark braucht, sollte das besser lassen. Underclock finde ich jedoch durchaus praktisch, da man so die Laufzeit deutlich verlängern kann. Ich selber betreibe kein UC, wenn ich jedoch länger keine Steckdose in Aussicht habe, und weiss dass ich das Tel brauche, würde ich es aber in Betracht ziehen.
pegasusq:
Der pegasusq(d*) ist ein ondemand basierender Govenor. Er unterscheidet sich in dem Sinne vom ondemand, weil er auf multi CPU ausgelegt ist. Also Dualcore, Quadcore usw. Der Govenor hat seine eigenen Hot Plug Einstellungen. Hot Plug bezeichnet man das Verhalten des zweiten Kerns, also wann er zugeschalten wird, wie lange er bei Abfall der Leistung noch eingeschaltet bleibt usw. Hot Plug Einstellungen die in ExTweaks eingestellt sind, werden beim pegasusq automatisch deaktiviert, und reaktiviert sobald man wieder auf einen anderen Govenor wechselt. Meine pegasusq Einstellungen sehen so aus:
sampling_rate: 40000 / Wie oft die CPU abgefragt wird, um zu entscheiden ob nach Oben oder Unten skaliert wird.
up_threshold: 90 / Grenzwert, ab dem hochskaliert wird
sampling_down_factor: 2 / Dient als Multiplikator des "sampling_rate" Wertes, um zu entscheiden wie schnell nach Neuberechnung der aktuellen Auslastung bei Vollast runter skaliert wird. "1" bedeutet "sampling_rate = "sampling_down_factor", jede andere Zahl multipliziert die 400000 mikrosekunden. Dieser Wert gilt nur für die oberen Frequenzen, oder hoher Auslastung. Beachte dass die CPU automatisch auf "max frequency" skaliert, wenn "max_load_freq" grösser ist als "up_threshold" x "current frequency". "max_load_freq" ist ein willkürlicher Wert, der aus "maximum of load_frequencies" berechnet wird. "load_frequency" ist auch ein willkürlicher Wert, welcher die Frequenz beschreibt, bei der das Gerät theoretisch mit 100% Auslastung umgehen kann, errechnet aus "load" x "average_frequency" (Durchschnitts-Frequenz)
ignore_nice_load: 0 / Auf "1" werden "low-level prozesse" beim skalierien ignoriert.
io_is_busy: 0
down_differential: 5 / Nachdem die Zeit von "sampling_rate* x "sampling_down_factor" verstrichen ist, wird Versucht eine niedrigere Frequenz zu wählen, welche aber nicht den "up_threshold" (85%) bei der nächsten Abfrage auslösen wird. Das "down_differential" ist auch dazu da, dass nicht zu schnell herunterskaliert wird. Gerechnet wird Folgendermassen: "Max_load_freq" (bei mir 1200mhz) wird gegen (up_threshold - down_differential) x "current frequency" (aktuelle Frequenz) gerechnet.
freq_step: 40 / 20!! / Definiert um wieviel Prozent der "max_frequency" hochskaliert werden soll, wenn die Auslastung den "up_threshold" erreicht. Mein Wert entspricht "20" = 1200mhz/100x20 = 240mhz. Das heisst, wenn bei 200mhz die 90% erreicht werden, skaliert die CPU 240mhz hoch, gerundet auf 100 = 300mhz = 500mhz entspricht dann der nächsten Frequenz. Der Wert von "40" scheint mir viel zu hoch, denn das würde bedeuten, dass sobald der up_threshold erreicht wird, die CPU 480mhz aufwärts skaliert, was auf 100er gerundet 500mhz entspricht! Man merkt die Ausprägung dieser 300mhz teilweise stark in CPU Spy, die werden mehr benutzt als die restlichen Schritten, je nach Nutzung natürlich. Die CPU kann ja auch in 100er Schritten skalieren, man ist nicht immer sofort von 200mhz auf 800mhz. Vorallem beim runter skalieren werden jegliche Frequenzen genutzt.
cpu_up_rate: 10 / Anzahl der Abfragen um die Auslastung beim hoch skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-up logic ausgeführt. Bevor die CPU hoch skaliert wird, bleibt die CPU auf "cpu_up_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz.
cpu_down_rate: 20 / Anzahl der Abfragen um die Auslastung beim runter skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-down logic" ausgeführt. Bevor also runter skaliert wird, bleibt die CPU auf "cpu_down_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz.
max_cpu_lock: 0 /
hotplug_lock: 0 /
dvfs_debug: 1 / "1" schaltet Govenor debugging ein.
hotplug_freq_ 1 1: 600000 / Schwelle ab wann der zweite Kern beim hoch skalierien zugeschaltet wird, wenn folgende Bedingungen auch erfüllt sind: ("minimum frequency" ist grösser oder gleich "hotplug_freq 1 1" und die Länge von "average_runque_minimum" grösser ist als "hotplug_rq_1_1") = Hot Plug IN second core.
hotplug_freq_ 2 0: 500000 / Schwelle ab wann der zweite Kern beim runter skalieren wieder ausgeschaltet wird, wenn folgende Bedingungen erfüllt sind: ("maximum frequency" ist weniger als "hotplug_freq 2 0" und die Länge von "average_runque__maximum" grösser oder gleich "hotplug_rq_2_0") Hot Plug OUT second core.
hotplug_rq :1 1: 300 / Schwellenwert für die Lauflänge der Warteschlange bis der zweite Kern zugeschaltet wird.
hotplug_rq: 2 0: 350 / Schwellenwert für die Lauflänge der Warteschlange bis der zweite Kern ausgeschaltet wird.
up_threshold_at_min_freq: 95 / Erklärt sich von selbst
freq_for_responsiveness: 10000 / Bis zu dieser Frequenz wird der up_threshold_at_min_freq als Trigger genutzt (95%). Danach löst der up_threshold den Trigger zum hoch skalieren aus (90%) Diese Frequenz wird auch dazu genutzt, um der CPU beim runter skalieren zu helfen die beste Frequenz zu finden. Eine, die beim nächsten Abfragen den "up_threshold" nicht sofort wieder auslöst. Bei der Auswertung der CPU Spy Kurven und tracken per "Cool Tool" hat sich herausgestellt, dass mit diesen Einstellungen nur die "grossen" Sprünge gemacht werden. Nach 100mhz kommt 400mhz, 700mhz usw. (freq_step: 20%), die anderen Frequenzen werden nicht genutzt. Ich hab diesen Werl nun wieder auf 100000 (100mhz) gestellt und würde euch raten, dies auch so zu machen.
Alles absolut smooth bei mir. Experimentiert mit diesen Einstellungen herum und findet was euch passt
Meine Settings:
Kernel: Siyah 3.2.5.2
Govenor: pegasusq
Sheduler: SIO
Frequenzen: 100-1200mhz in 100er Steps
Kein CPU Undervolt
GPU: 66/160/267
Und nun viel Spass! Bei Fragen und Unklarheiten, meldet euch
hells
hoch.
