Android Grundlagen – Energy Aware Scheduling (EAS) erklärt.

Heute ist das Energiemanagement bei Linux-Systemen über die unterschiedlichsten Sub-Systemen implementiert, die in weiten Teilen unkoordiniert zueinander arbeiten. Dies macht die Adaptierung neuer Plattformen und deren Tuning zu einer sehr herausfordernden und komplexen Aufgabe. ARM und Linaro haben sich daher zusammengeschlossen, um am „Energy Aware Scheduling“ zu arbeiten und dessen Entwicklung voran zu treiben, eine Technologiedie das Energiemanagement optimiert, indem sie es zentralisiert und dessen Tuning So einfacher gestaltet. Dies wird unter Anderem den Linux Support für fortschrittliche Multi-Kern SoC’s verbessern, welche aktuelle und zukünftige mobile Geräte antreiben. Als Abschluss meiner Reihe zu Scheduling-Methoden im Linux und Android Bereich, stelle ich Euch den „Energy Aware Scheduler“ aus diesem Grunde heute vor.

Der existierende „Completely Fair Scheduler“ hat eine durchsatzbasierte Politik. So wird er einen neuen Task, so denn ein CPU Idle, d.h. untätig ist, immer an eben diesen Idle CPU zuweisen. Eben dies muss aber nicht dien richtige Entscheidung sein, betrachtet man den geringst möglichen Energieverbrauch. Aus eben diesem Gesichtspunkt implementiert der Energy Aware Scheduler (EAS) ein verbessertes Energiemanagment, ohne die Performance zu beeinträchtigen. Das Projelt zur Entwicklung des Energy Aware Scheduling besteht dabei aus eine Viezahl an Teilaufgaben:

EAS-task-image

Das Ziel ist es ein generisches Energiebewusstsein im Upstream-Linux zu schaffen:

  1. Mit einem sauberen, generischen Design, um eine breite Palette von CPU-Topologien zu unterstützen.
  2. Basierend auf wissenschaftlichen, gemessenen Energiemodelldaten statt magischen Tunables.
  3. Bereitstellung einer qualitativ hochwertigen Baseline-Lösung, die genutzt werden kann wie sie ist, oder erweitert werden kann, wie benötigt.
  4. Designed-for-mainline => Reduktion der Software-Wartungskosten.

EAS vereint 3 separate Frameworks im Linux-Kernel, die derzeit nur lose miteinander verbunden sind:

  • Linux Completely Fair Scheduler
  • Linux cpuidle
  • Linux cpufreq

Diese bestehenden Rahmenbedingungen haben ihre eigenen politischen Mechanismen, die Entscheidungen unabhängig treffen.

Die optimale Lösung besteht darin, diese Funktionen vollständig in den Linux-Scheduler selbst zu integrieren, mit ausreichender Information, um die energieeffizientesten Scheduling-Entscheidungen zu ermöglichen.

Ein typischer ARM-Multi-Core-SoC hätte folgende Spannungs- und Frequenzdomänen:

ARM-voltage-EAS-blog

Idealerweise wird jeder Cluster mit einer eigenen, unabhängigen Frequenz und Stromspannung operieren. Durch die Reduktion der Frequenz und Spannung kann so eine substanzielle Energieersparnis realisiert werden. Dies gestattet es, die Energie/Perfirmance per Cluster akkurat zu kontrollieren, und sie maßgeschneidert auf den zu erbringenden Workload anzupassen.

Ein generischer energiemodellbasierter Ansatz wird voraussichtlich eine breite Palette aktueller und zukünftiger CPU-Topologien unterstützen, darunter SMP, Multi-Cluster-SMP (z. B. 8-Core Cortex-A53-Produkte) sowie traditionelle ARM big.LITTLE.

Scheduler Idle-State Awareness

Die Scheduler-Idle-Erweiterung macht den Scheduler auf den Leerlaufzustand der CPUs aufmerksam. Beim Aufwachen einer CPU wird sie nun immer die CPU im geringsten Leerlaufzustand (Idle-State) auswählen und die Weckzeit und Energie minimieren.

Im folgenden Beispiel muss ein neuer Task aufgeweckt werden, aber er wird nicht auf CPU#0 passen, da die aktuelle Kapazität fast vollständig ausgelastet ist. Mit der integrierten sched-idle wird die neue Aufgabe immer auf CPU# l1 gesetzt, da sich diese im niedrigsten Leerlaufzustand (WFI) befindet und der andere Cluster im C2-Shutdown bleibt. Dies ist die Option der niedrigsten Energie und schnellsten Antwort.

EAS-blog-4

DVFS (cpufreq) Verbesserungen

Die bestehende cpufreq-Implementierung ist eine Erweiterung des Linux-Kernels, die einen Sampling-basierten Ansatz zur Betrachtung der CPU-Zeit im Leerlauf mit einigen Heuristiken zur Steuerung des CPU Operating Performance Point (OPP) verwendet. Es gibt eine Reihe von Nachteilen für diesen Ansatz:

  1. Sampling-basierte Governors sind langsam zu reagieren und schwer zu tunen.
  2. Sampling zu schnell: OPP ändert sich für kleine Auslastungsspitzen.
  3. Sampling zu langsam: Eine plötzliche Explosion der Auslastung könnte nicht die notwendige OPP-Änderung in der benötigten Zeit durchführen – Reaktionszeit könnte schlecht sein.
  4. Nur der gesamten CPU-Belastung bewusst, und ist nicht der Task-Migration.

EAS-blog-5

Neuer scheduler-getriebener DVFS (sched-DVFS)

Mit dem Scheduler Task-Usage-Tracking, einer Funktion, die der Mainline-Kernel bereits unterstützt, wird jeder OPP-Übergang sofort passieren, basierend auf dem gespeicherten nachverfolgten Last des Task.

EAS-blog-6.jpg

Mit sched-cpufreq, ändert sich die CPU-Kapazität für den kleinen Cluster sofort, wenn der neue Task auf CPU#1 platziert wird. Hierbei handelt es sich um den Verlauf der Task, der intern als Teil des CFS-Schedulers im Kernel gespeichert wird. Dies ist eine gute Annäherung für viele Tasks, die ein gleichmäßiges CPU-Lastverhalten haben.

Frequenz und Kapazität invariantes Last Tracking

Das „Per-Entity Load Tracking“ (PELT) Framework im Linux Kernel bestimmt die Last eines Task, indem es die Nutzung der CPUs betrachtet. Das bestehende Design von PELT verfolgt die CPU-Auslastung, verfolgt aber nicht die Last unterschiedlicher CPUs mit unterschiedlichen Frequenzen oder mit unterschiedlicher Leistung pro MHz.

Kapazität

Sie ist ein Maß für die Verarbeitungsfähigkeit einer CPU. ARM-Patches beinhalten Verbesserungen für die Kapazitätserweiterung mit zusätzlicher Skalierung für Mikroarchitektur und aktuelle Betriebsfrequenz. Die CPU-Kapazität an verschiedenen Betriebspunkten basiert auf der Messung einiger Standard-Benchmark-Metriken, z.B. „Sysbench“.

Nutzung

Traditionell wurde die Nutzung mit der Laufzeit verknüpft. ARM-Fundament-Patches erweitern dies, um die Häufigkeit und Leistung der CPU zu berücksichtigen.

EAS-8
Alte Auslastungsberechnung
EAS-image-9
Die neue Auslastungsrechnung berücksichtigt die Häufigkeit und die Mikroarchitektur

Energie Modell

Das EAS-Energiemodell ist das letzte Stück, das dem CFS eine energiebewusste Aufgabenstellung ermöglicht. Es erlaubt dem Kernel, zur Laufzeit zu entscheiden, welche Scheduling-Entscheidungen die besten für den niedrigsten Energieverbrauch sind. Die energiebewusste Politik ist es, die immer den CPU mit ausreichender Restkapazität und kleinsten Energieauswirkungen auswählt.

Dies entfernt auch die magischen Tunables in einigen der Power-Management-Frameworks derzeit – man muss nun tatsächlich in den Code sehen und ihnnverstehen, um zu wissen was diese magischen Tunables genau machen. Betrachtet man zum Beispiel die big.LITTLE HMP-Schwellenwerte, die Scheduler-Tunables und sogar die interaktiven Governor-Tunables.

EAS-image-10.jpg

Das Plattform-Energie-Modell ist ein genaues Basismodell der dynamischen und statischen Leistung, die von den CPUs im System verwendet wird.

EAS-image-11.jpg
Typische big.LITTLE CPU Power/Performance Kurven

Für jede CPU enthält das Energiemodell die folgenden Informationen

EAS-blog-image-12

Optionen einen, zu weckenden, Task zu platzieren

Wie in der folgenden Abbildung zu sehen ist, kann ein neuer zu weckender Task sinnvoll auf eine der beiden CPUs – CPU#1 oder CPU#3 vergeben werden. Mit dem aktuellen Mainline-Scheduler können entweder CPU#1 oder CPU#3 gewählt werden.

EAS-image-14.jpg

Der EAS berücksichtigt die Energiekosten der beiden Optionen:

CPU#1: Betriebspunkt muss sowohl für CPU#0 als auch CPU#1 verschoben werden

CPU#3: keine Betriebspunktänderung, aber höhere Leistung nach Power/Performance-Grafik unten verwendet

EAS-image-15
EAS big.LITTLE CPU Power/Performance Kurven

Basierend auf dem oben genannten wird EAS wahrscheinlich CPU#1 wählen, da die geringen zusätzlichen Energiekosten für die Erhöhung des OPP der CPU#0 (und CPU#1 durch Implikation – da beide CPUs im gleichen Frequenzbereich in diesem Beispiel sind) nicht signifikant ist, verglichen mit der besseren Leistungsfähigkeit der Ausführung der Aufgabe auf CPU#1 statt CPU#3. Die Schlüsselgrundstücke sind es, die Intensität der Aufgabe zu verstehen (durch PELT mit Frequenz- und Mikroarchitektur-Invarianz).

EAS bewertet nicht alle möglichen Optionen. Das kann Performance-Hits in den wichtigsten Scheduler-Pfaden einführen. Stattdessen verkleinert EAS den Suchraum auf:

  • CPU die Aufgabe lief auf letztes Mal.CPU gewählt durch eine einfache Heuristik, die funktioniert, wo die Aufgabe am besten passt.
  • Basierend auf dem Energiemodell wertet die EAS aus, welche dieser beiden Optionen am energieeffizientesten ist.

SchedTune

Der „Interaktive Gouvernor“ erschien 2010 auf Android und hat sich als eine sehr beliebte Lösung zur Maximierung der Akkulaufzeit erwiesen, während er einen hohen Betriebspunkt für interaktive Aufgaben bietet. Er wurde jedoch nicht in den Linux-Kernel integriert. Es besteht ein beträchtliches Interesse daran, eine Frequenz-Boost-Fähigkeit im Mainline-Linux – als Teil von cpufreq (und möglicherweise in Zukunft dem EAS) – zu integrieren.

Es gab eine wiederholte Forderung, einen einzigen, einfach abstimmbaren „Knopf“ zu haben, der die Auswahl eines energieeffizienten Betriebs an einem Ende und Hochleistungsbetrieb am anderen Ende erlaubt. Mit sched-DVFS und EAS ist die Bühne für die Implementierung einer solchen zentralen Tunable bereitet. ARMs Vorschlag für diese Tunable heißt SchedTune.

SchedTune fügt einen zusätzlichen „Spielraum“ in die getrackte Last von PELT hinzu. Sched-DVFS und EAS verwenden diese „geboostete“ getrackte Last, wie gewohnt, bei der Auswahl von Arbeitspunkten. Die Größe des Spielraumes wird durch einen einzigen Benutzerraum gesteuert, der abstimmbar ist.

EAS-image-16.jpg
SchedTune Kapazität/Performance Kurven im zeitlichen Verlauf

Wenn der Task größer erscheint, wird die zugeordnete MHz von cpufreq/sched-cpufreq höher sein. Diese einfache Technik erlaubt die Auswahl eines geeigneten Energie-/Performancepunktes, der die beste interaktive Antwort für das System bietet.

Nachlese

Bis zum heutigen Zeitpunkt befindet sich der Energy-Aware-Scheduler in der Entwicklung, an welcher Teams von ARM und Linaro kollaborieren. Bis zum Abschluss wird noch ein beträchtliches Maß an Zeit ins Land gehen, obschon der EAS – in der Version 1.x – bereits in den ersten Android Custom Kernels, sowie den Google Pixel Smartphones aus dem vergangenen Jahr zum Einsatz kommt. Das Ganze geschieht mit beachtlichem Erfolg in der Energieeffizienz, bei einem hohen Grad an Performance – wo benötigt. Wir dürfen also gespannt sein auf dieses, wie auch die kommenden Jahre, in denen man mit Sicherheit beträchtliche Energiesparpotentiale durch den Einsatz des EAS erkennen wird. Auch Diskussionen über eine immer höhere Akku-Kapazität könnten mit Hilfe des neuen Schedulers in andere, neue und noch unbekannte Bahnen zu lenken.

Ich hoffe allen Technikbegeisterten und -interessierten einen guten und ausreichend knapp gefassten Überblick über die Energie-/Performancesteuerung alter und neuer Linux-/Android-Systeme gegeben zu haben. Falls Ihr Anregungen und/oder Anmerkungen habt, hinterlasst mir diese in den Kommentaren. Ich werde dann – so denn möglich – noch einmal Vertiefungen zu den Fragen und Anregungen versuchen nachzuliefern.

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a website or blog at WordPress.com

Nach oben ↑

%d Bloggern gefällt das: