Kapazitätsbedingte Ruckler identifizieren

Die Kapazität ist die Gesamtmenge einer Ressource (CPU, GPU usw.), die ein Gerät über einen bestimmten Zeitraum hat. Auf dieser Seite wird beschrieben, wie du kapazitätsbedingte Ruckler identifizieren und beheben kannst.

Regler reagiert langsam

Um Ruckler zu vermeiden, muss der CPU-Taktregler schnell auf Arbeitslasten mit kurzen Spitzen reagieren können. Die meisten UI-Apps folgen demselben grundlegenden Muster:

  1. Der Nutzer liest den Bildschirm.
  2. Der Nutzer berührt den Bildschirm: Tippt auf eine Schaltfläche, scrollt usw.
  3. Der Bildschirm scrollt, ändert die Aktivität oder wird auf irgendeine Weise animiert, als Reaktion auf eine Eingabe.
  4. Das System wird ruhiggestellt, während neue Inhalte angezeigt werden.
  5. Der Nutzer liest wieder den Bildschirm.

Auf Pixel- und Nexus-Geräten wird der Touch-Boost implementiert, um das Verhalten des CPU-Taktreglers (und ‑Schedulers) bei Berührung zu ändern. Um eine langsame Steigerung auf eine hohe Taktfrequenz zu vermeiden, die dazu führen kann, dass das Gerät bei Berührung Frames verliert, wird beim Touch-Boost in der Regel eine Mindestfrequenz für die CPU festgelegt, damit bei Berührung ausreichend CPU-Kapazität verfügbar ist. Ein Stockwerk bleibt nach dem Berühren einige Zeit bestehen (in der Regel etwa zwei Sekunden).

Auf Pixel wird außerdem die cgroup „schedtune“ verwendet, die von der energiebewussten Planung (Energy Aware Scheduling, EAS) bereitgestellt wird, als zusätzliches Signal für die Touch-Beschleunigung: Die wichtigsten Apps erhalten über „schedtune“ ein zusätzliches Gewicht, damit sie genügend CPU-Kapazität für eine schnelle Ausführung erhalten. Bei Nexus 5X und 6P ist die Leistungslücke zwischen den kleinen und großen CPU-Clustern (A53 und A57) viel größer als bei Pixel mit der Kryo-CPU. Wir haben festgestellt, dass der kleine CPU-Cluster nicht immer für ein flüssiges UI-Rendering ausreicht, insbesondere angesichts anderer Ursachen für Ruckler auf dem Gerät.

Daher ändert der Touch-Boost auf Nexus 5X und 6P das Verhalten des Schedulers, damit Apps im Vordergrund mit höherer Wahrscheinlichkeit auf die großen Kerne umgestellt werden. Das ist konzeptionell ähnlich wie die Untergrenze für die CPU-Frequenz. Ohne die Änderung am Scheduler, durch die Apps im Vordergrund mit höherer Wahrscheinlichkeit auf den großen CPU-Cluster verschoben werden, haben Apps im Vordergrund möglicherweise nicht genügend CPU-Kapazität zum Rendern, bis der Scheduler entscheidet, den Thread auf einen großen CPU-Kern zu laden. Durch die Änderung des Scheduler-Verhaltens während des Touch-Boosts ist es wahrscheinlicher, dass ein UI-Thread sofort auf einem großen Kern ausgeführt wird, um Ruckler zu vermeiden, ohne dass er immer auf einem großen Kern ausgeführt wird, was sich erheblich auf den Energieverbrauch auswirken könnte.

Thermische Drosselung

Die thermische Drosselung tritt auf, wenn das Gerät seine thermische Gesamtleistung reduzieren muss. Dies geschieht in der Regel durch eine Verringerung der CPU-, GPU- und DRAM-Taktfrequenzen. Das führt nicht überraschend oft zu Rucklern, da das System möglicherweise nicht mehr genügend Kapazität für das Rendern innerhalb eines bestimmten Zeitabschnitts bereitstellen kann. Die einzige Möglichkeit, das thermische Drosseln zu vermeiden, besteht darin, weniger Strom zu verbrauchen. Es gibt nicht viele Möglichkeiten, dies zu tun. Basierend auf unseren Erfahrungen mit früheren SOCs haben wir jedoch einige Empfehlungen für Systemanbieter.

Achten Sie beim Erstellen eines neuen SOC mit heterogenen CPU-Architekturen darauf, dass sich die Leistungs-/W-Kurven der CPU-Cluster überschneiden. Die Gesamtleistungs-/Leistungskurve für den gesamten Prozessor sollte eine durchgehende Linie sein. Aufgrund von Unterbrechungen in der Leistungs-/Leistungskurve müssen der Scheduler und der Taktregler erraten, was eine Arbeitslast benötigt. Um Ruckler zu vermeiden, geben der Scheduler und der Taktregler der Arbeitslast mehr Kapazität als erforderlich. Dies führt zu einem zu hohen Energieverbrauch, was zu einer thermischen Drosselung beiträgt.

Stellen Sie sich ein hypothetisches SOC mit zwei CPU-Clustern vor:

  • Cluster 1, der kleine Cluster, kann zwischen 100 und 300 mW verbrauchen und erzielt je nach Taktfrequenz einen Durchsatz von 100 bis 300.
  • Cluster 2, der große Cluster, kann zwischen 1.000 und 1.600 mW verbrauchen und erzielt je nach Taktfrequenz zwischen 800 und 1.200 Punkte im selben Durchsatz-Benchmark.

Je höher der Wert, desto schneller ist die Leistung. Höhere Geschwindigkeit bedeutet zwar nicht unbedingt eine bessere Leistung, aber auch einen höheren Stromverbrauch.

Wenn der Scheduler der Meinung ist, dass eine UI-Arbeitslast einen Wert von 310 bei diesem Durchsatz-Benchmark erfordert, ist die beste Option, um Ruckler zu vermeiden, den großen Cluster mit der niedrigsten Taktfrequenz auszuführen, was zu einem erheblichen Energieverbrauch führt. (Dies hängt vom Verhalten des CPU-Inaktivitätsstatus und vom Race-to-Idle-Verhalten ab. SOCs mit kontinuierlichen Leistungs-/Leistungskurven lassen sich leichter optimieren.)

Zweitens: Verwenden Sie cpusets. Sie müssen CPU-Sets in Ihrem Kernel und in Ihrer BoardConfig.mk aktiviert haben. Außerdem müssen Sie die tatsächlichen cpuset-Zuweisungen in Ihrer gerätespezifischen init.rc einrichten. Einige Anbieter deaktivieren diese Funktion in ihren BSPs in der Hoffnung, dass sie das Scheduler-Verhalten mit anderen Hinweisen beeinflussen können. Wir halten das für unsinnig. CPU-Sets sind nützlich, um dafür zu sorgen, dass die Lastverteilung zwischen den CPUs so erfolgt, dass sie dem entspricht, was der Nutzer tatsächlich auf dem Gerät tut.

Der ActivityManager weist Apps basierend auf ihrer relativen Wichtigkeit (oben, Vordergrund, Hintergrund) verschiedenen CPU-Sets zu. Wichtigere Apps erhalten mehr Zugriff auf CPU-Kerne. So wird die Dienstqualität für Apps im Vordergrund und für die Top-Apps sichergestellt.

CPU-Sets sind bei homogenen CPU-Konfigurationen nützlich. Sie sollten jedoch kein Gerät mit einer heterogenen CPU-Konfiguration ausliefern, ohne dass CPU-Sets aktiviert sind. Nexus 6P ist ein gutes Modell für die Verwendung von cpusets in heterogenen CPU-Konfigurationen. Verwenden Sie es als Grundlage für die Konfiguration Ihres eigenen Geräts.

CPU-Sets bieten auch Vorteile in Bezug auf den Energieverbrauch, da Hintergrundthreads, die nicht leistungskritisch sind, niemals auf große CPU-Kerne verteilt werden, wo sie ohne erkennbaren Vorteil für den Nutzer deutlich mehr Strom verbrauchen könnten. So lässt sich auch die thermische Drosselung vermeiden. Die thermische Drosselung ist zwar ein Kapazitätsproblem, aber Verbesserungen beim Jitter haben bei der thermischen Drosselung einen überproportionalen Einfluss auf die Leistung der Benutzeroberfläche. Da das System näher an seiner Fähigkeit liegt, 60 fps zu rendern, ist weniger Jitter erforderlich, um einen Frame-Drop zu verursachen.