Sunny
Gesperrt
- 34.420
Hallo liebes Forum und Freunde des Axon7
The Schwifty Kernel (Yeahhh, Get Schwifty)
Der Schwifty Kernel "goes" Treble
Nur ein paar Tage nach den ersten Treble Rom's für unser Axon7 gibt es nun schon Dank SaintZ93 von XDA den ersten Treble fähigen Kernel für unser Axon7.
Ein paar Worte des Entwicklers
Hallo Jungs Willkommen beim Schwifty Kernel! Wenn Sie die Show "Rick and Morty" sehen, werden Sie verstehen, warum ich es so genannt habe, wenn Sie auch nicht gut verstehen, entweder YouTube es oder einfach keine Sorge und genießen Sie die sh * t aus dem Kernel sowieso hehe. Okay, lassen Sie sich schwifty, hier ist alle Informationen über den Kernel in einer Weise, die Ihnen helfen wird, zu entscheiden, wie Sie Ihr Telefon einrichten wollen!
I/O Scheduler Information - I/O
NOOP - Fügt alle eingehenden I/O-Anfragen in eine erste in der ersten Warteschlange ein und implementiert die Anfrage-Verschmelzung. Am besten mit Speichergeräten, die nicht von mechanischer Bewegung abhängig sind, um auf Daten zuzugreifen (ja, wie unsere Flash-Laufwerke). Vorteil dabei ist, dass Flash-Laufwerke keine Neuordnung mehrerer I/O-Anfragen erfordern, anders als bei normalen Festplatten.
DEADLINE - Das Ziel des Deadline Schedulers ist es, zu versuchen, eine Start Servicezeit für eine Anfrage zu garantieren. Sie tut dies, indem Sie allen I/O-Operationen eine Frist auferlegt, um das Aushungern von Anträgen zu verhindern. Es unterhält auch zwei Termin Schlangen, zusätzlich zu den sortierten Warteschlangen (sowohl lesen als auch schreiben). Termin Warteschlangen werden grundsätzlich nach ihrer Frist (der Verfallszeit) sortiert, während die sortierten Warteschlangen nach der Sektornummer sortiert werden. Bevor Sie der nächsten Anfrage dienen, entscheidet der Terminplaner, welche Warteschlange Sie verwenden sollen. Lese Schlangen haben eine höhere Priorität, da Prozesse in der Regel auf Leseoperationen blockieren. Als nächstes prüft der Terminplaner, ob die erste Anfrage in der Deadline-Warteschlange abgelaufen ist. Ansonsten bedient der Scheduler eine Reihe von Anfragen aus der sortierten Warteschlange. In beiden Fällen bedient der Scheduler auch eine Reihe von Anfragen, die der gewählten Anfrage in der sortierten Warteschlange folgen.
BFQ - Statt der Zeit Scheiben Zuweisung durch CFQ weist bfq Budgets zu. Die Festplatte wird einem aktiven Prozess gewährt, bis Ihr Budget (Anzahl der Sektoren) ausläuft. Bfq weist hohe Budgets für nicht lesbare Aufgaben zu. Das Budget, das einem Prozess zugeordnet wird, variiert im Laufe der Zeit in Abhängigkeit von seinem Verhalten.
ZEN & ZEN v2 - Basierend auf dem NOOP, Deadline und SIO I/O Schedulers. Es ist ein FCFS (First Come, First Serve) basierter Algorithmus, aber es ist nicht streng FIFO. Zen macht keine Sortierung. Es verwendet Fristen für Fairness und behandelt synchrone Anfragen mit Vorrang vor asynchronen.
DEADLINE - Das Ziel des Deadline Schedulers ist es, zu versuchen, eine Start Servicezeit für eine Anfrage zu garantieren. Sie tut dies, indem Sie allen I/O-Operationen eine Frist auferlegt, um das Aushungern von Anträgen zu verhindern. Es unterhält auch zwei Termin Schlangen, zusätzlich zu den sortierten Warteschlangen (sowohl lesen als auch schreiben). Termin Warteschlangen werden grundsätzlich nach ihrer Frist (der Verfallszeit) sortiert, während die sortierten Warteschlangen nach der Sektornummer sortiert werden. Bevor Sie der nächsten Anfrage dienen, entscheidet der Terminplaner, welche Warteschlange Sie verwenden sollen. Lese Schlangen haben eine höhere Priorität, da Prozesse in der Regel auf Leseoperationen blockieren. Als nächstes prüft der Terminplaner, ob die erste Anfrage in der Deadline-Warteschlange abgelaufen ist. Ansonsten bedient der Scheduler eine Reihe von Anfragen aus der sortierten Warteschlange. In beiden Fällen bedient der Scheduler auch eine Reihe von Anfragen, die der gewählten Anfrage in der sortierten Warteschlange folgen.
BFQ - Statt der Zeit Scheiben Zuweisung durch CFQ weist bfq Budgets zu. Die Festplatte wird einem aktiven Prozess gewährt, bis Ihr Budget (Anzahl der Sektoren) ausläuft. Bfq weist hohe Budgets für nicht lesbare Aufgaben zu. Das Budget, das einem Prozess zugeordnet wird, variiert im Laufe der Zeit in Abhängigkeit von seinem Verhalten.
ZEN & ZEN v2 - Basierend auf dem NOOP, Deadline und SIO I/O Schedulers. Es ist ein FCFS (First Come, First Serve) basierter Algorithmus, aber es ist nicht streng FIFO. Zen macht keine Sortierung. Es verwendet Fristen für Fairness und behandelt synchrone Anfragen mit Vorrang vor asynchronen.
Interactive - Interactive skaliert die uhrgeschwindigkeit über den Verlauf eines Timers, der vom Kernel-Entwickler (oder Benutzer) gesetzt wird. Mit anderen Worten: Wenn eine Anwendung eine Rampe auf maximale uhrgeschwindigkeit fordert (indem Sie 100% Last auf die CPU legt), kann ein Benutzer eine andere Aufgabe ausführen, bevor der Gouverneur beginnt, die CPU-Frequenz zu reduzieren. Durch diesen Timer ist Interactive auch besser darauf vorbereitet, zwischen uhrgeschwindigkeiten zu verwenden, die zwischen den minimalen und maximalen CPU-Frequenzen fallen. Es ist deutlich ansprechender als OnDemand, weil es bei der Skalierung auf maximale Frequenz schneller ist. Interactive geht auch davon aus, dass einem Benutzer, der den Bildschirm dreht, in Kürze der Benutzer folgen wird, der mit einer Anwendung auf seinem Gerät interagiert. Aus diesem Licht löst Screen on eine Rampe auf maximale uhrgeschwindigkeit aus, gefolgt von dem oben beschriebenen Timer-Verhalten. Interactive ist der Standard-Gouverneur der Wahl für die heutigen Smartphone-und Tablet-Hersteller.
Ondemand - OnDemand ist einer der ursprünglichen und ältesten Gouverneure, die auf dem Linux-Kernel verfügbar sind. Wenn die Last, die auf der CPU platziert wird, die festgelegte Schwelle erreicht, wird der Regler schnell auf die maximale CPU-Frequenz aufsteigen. Es hat aufgrund dieser hochfrequenten Voreingenommenheit eine hervorragende Flüssigkeit, kann aber auch relativ negative Auswirkungen auf die Akkulaufzeit gegenüber anderen Gouverneuren haben. OnDemand wurde in der Vergangenheit häufig von Smartphone-Herstellern gewählt, weil es gut getestet und zuverlässig ist, aber es ist jetzt veraltet und wird durch Googles interaktiven Gouverneur ersetzt.
Performance - Setzt die Frequenz auf die maximal verfügbare Frequenz. Dieser Regler gibt UINT_MAX immer als Frequenz zurück, so dass das devfreq-Framework jederzeit die höchste verfügbare Frequenz zurückgibt.
Powersave - Setzt die Frequenz auf die minimale verfügbare Frequenz. Dieser Regler gibt immer 0 als Frequenz zurück, so dass das devfreq-Framework die niedrigste verfügbare Frequenz jederzeit zurückgibt.
Userspace - Setzt die Frequenz beim angegebenen Benutzer ein. Dieser Gouverneur gibt dem Benutzer die konfigurierte Frequenz zurück, wenn es einen Input zu/sys/devices/.../Power/devfreq_set_freq.. andernfalls ändert der Gouverneur nicht die frequnschige, die bei der Initialisierung angegeben wird.
Ondemand - OnDemand ist einer der ursprünglichen und ältesten Gouverneure, die auf dem Linux-Kernel verfügbar sind. Wenn die Last, die auf der CPU platziert wird, die festgelegte Schwelle erreicht, wird der Regler schnell auf die maximale CPU-Frequenz aufsteigen. Es hat aufgrund dieser hochfrequenten Voreingenommenheit eine hervorragende Flüssigkeit, kann aber auch relativ negative Auswirkungen auf die Akkulaufzeit gegenüber anderen Gouverneuren haben. OnDemand wurde in der Vergangenheit häufig von Smartphone-Herstellern gewählt, weil es gut getestet und zuverlässig ist, aber es ist jetzt veraltet und wird durch Googles interaktiven Gouverneur ersetzt.
Performance - Setzt die Frequenz auf die maximal verfügbare Frequenz. Dieser Regler gibt UINT_MAX immer als Frequenz zurück, so dass das devfreq-Framework jederzeit die höchste verfügbare Frequenz zurückgibt.
Powersave - Setzt die Frequenz auf die minimale verfügbare Frequenz. Dieser Regler gibt immer 0 als Frequenz zurück, so dass das devfreq-Framework die niedrigste verfügbare Frequenz jederzeit zurückgibt.
Userspace - Setzt die Frequenz beim angegebenen Benutzer ein. Dieser Gouverneur gibt dem Benutzer die konfigurierte Frequenz zurück, wenn es einen Input zu/sys/devices/.../Power/devfreq_set_freq.. andernfalls ändert der Gouverneur nicht die frequnschige, die bei der Initialisierung angegeben wird.
GPU Governors:
- Adreno Idler - Es handelt sich um einen Leerlauf-Algorithmus, eine effiziente Umgehung für MSM-adreno-TZ-Overheads. Hauptziel ist es, den Stromverbrauch zu senken und gleichzeitig die Leistungsfähigkeit zu erhalten. Da MSM-adreno-TZ dazu neigt, die niedrigste Frequenz auch im Leerlauf zu verwenden, ersetzt adreno Idler den Algorithmus von MSM-adreno-TZ, wenn es um die Berechnung der Leerlauf Frequenz geht (meist nach OnDemand-Methode). Die höheren Frequenzen werden mit diesem Algorithmus nicht berührt, so dass hoch fordernde Spiele (höchstwahrscheinlich) nicht unter einer Verschlechterung der Leistung leiden werden.
- Simple - Eine Open-Source-Alternative zu Qualcomm es geschlossenen Gouverneuren. Von Faux123 entwickelt, ist es hochgradig anpassbar, was eine feinere Kontrolle darüber ermöglichen wird, wie die GPU auf und ab skaliert.
- Simple_ondemand -Wie der Name schon sagt, handelt es sich um eine einfachere Version des CPU-Gouverneurs OnDemand. simple_ondemand wird die Frequenz erhöhen, wenn eine Last erkannt wird. Es hat eine gute Balance zwischen Leistung und Akku-Einsparung.
- msm-adreno-tz - Der Standard-GPU-Gouverneur, der von Qualcomm für Ihren adreno GPUs verwendet wird. Es basiert auf dem OnDemand-Gouverneur, ist aber auf Leistung ausgerichtet, daher sollte es eine bessere Leistung in spielen, aber weniger Akkulaufzeit geben.
- Performance - Wie der Name schon sagt, hält dies Ihre GPU auf der maximalen Frequenz. Dies ist ein Gouverneur, wenn Sie die bestmögliche Erfahrung in spielen wollen, aber Sie kümmern sich nicht um Ihre Akkulaufzeit.
- Powersave - Wie der CPU-Regler hält dies Ihre GPU auf der geringstmöglichen Frequenz. Beste Akkulaufzeit, extremer Rückstand in spielen.
- Userspace - Dieser Gouverneur erlaubt es dem Benutzer im Grunde, eine gewünschte Frequenz zu setzen, damit die GPU laufen kann.
- cpubw_hwmon - Ein Hardware-Monitor-basierter Gouverneur, der versucht, die von CPU und anderer Hardware benötigte Bandbreite (BW) zu bestimmen. Da es die Bandbreite in Wahl Intervallen einprobt, wurde es dazu gebracht, auf die Leistung ausgerichtet zu sein, um die möglichen langsameren Reaktionszeiten bei schweren Belastungen auszugleichen.
- MSM Cpufreq - Der MSM cpufreq Governor bestimmt die CPU auf der Grundlage der aktuellen CPU-Frequenz aller aktiven CPUs zur DDR-Bandbreiten Abstimmung. Mit anderen Worten, dieser Gouverneur skaliert auf CPU-Nutzung, was mehr Leistung bedeuten könnte.
Bewegte Core-Steuerung auf Kernel verlegte die Kern Steuerung vom Out-of-Tree-Modul in den eigentlichen Kernel.
Core Control überwacht die Belastung von CPUs und steuert, wie viele CPUs zur Verfügung stehen, damit das System zu jedem Zeitpunkt verwendet werden kann. Das kann helfen, Strom zu sparen. Die Kern Steuerung kann über die sysfs-Schnittstelle konfiguriert werden.
Bewegte Core Control Trace-Ereignisse auf Scheduler fügten einen Knopf hinzu, um die core_ctl (Core Control) zu deaktivieren-die CPU-Hotplug-Tests funktionieren nicht mit core_ctl, die statisch in Kernel kompiliert wurden.
Eine Schnittstelle zur Verfügung stellen, um den Hotplug von core_ctl zu deaktivieren.
Vieles mehr
Core Control überwacht die Belastung von CPUs und steuert, wie viele CPUs zur Verfügung stehen, damit das System zu jedem Zeitpunkt verwendet werden kann. Das kann helfen, Strom zu sparen. Die Kern Steuerung kann über die sysfs-Schnittstelle konfiguriert werden.
Bewegte Core Control Trace-Ereignisse auf Scheduler fügten einen Knopf hinzu, um die core_ctl (Core Control) zu deaktivieren-die CPU-Hotplug-Tests funktionieren nicht mit core_ctl, die statisch in Kernel kompiliert wurden.
Eine Schnittstelle zur Verfügung stellen, um den Hotplug von core_ctl zu deaktivieren.
Vieles mehr
Installationsanleitung:
- Bootet in die Recovery
- Flasht Schwifty Kernel (entweder Treble oder "normal")
- Wipe Dalvik & Cache
- Re-Flash Magisk?*
Herzlichen Dank an die Devs:
Für Ihre Hilfe bei diesem Projekt
Entwickler:
SaintZ93
SourceCode:SaintZ13/schwifty_oreo
Original Thread auf XDA
Version Information:
Status: Stabil
Current Stable Version: vR5.8
Stable Release Date: 09.11.2018
Basic Specifications/Information:
Based On Axon 7 B12 Kernel Source (Thanks to @OrdenKrieger)
Updated to the latest linux kernel source (3.18.117)
Built with Linaro Toolchain
Erlaubt dem Kernel 5-10 Sekunden, sich nach dem Booten "einzusiedeln", um eine bessere Nutzung zu ermöglichen
Kernel Update: 09.11.2018 (Es scheint Bugs mit diesem Build zu geben siehe Beitrag, danke @cybertronic
)Thread Updated: 26.11.2018
Viel Spaß beim flashen und ausprobieren dieses tollen Kernels
LG
Sunny
Zuletzt bearbeitet:
