Forbedre Exynos 9810 Galaxy S9: Del 2 - Fange opp med Snapdragon

Etter vår gjennomgang av Galaxy S9 har det vært mye diskusjon om både ytelsen og batterilevetiden til Exynos 9810 varianter av Galaxy S9. I den opprinnelige anmeldelsen hadde jeg identifisert noen få sentrale problemer med plattformen som jeg hadde vurdert å være den mest negative tilskrivningen av telefonens dårlige egenskaper. I et første stykke etter gjennomgangen Jeg gjorde noen få mindre endringer i kjernen, som allerede syntes å ha hatt batterilevetid i vår surfingstest, og endret ytelsesegenskapene til telefonen for å få det positive.

I den forrige artikkelen bemerket jeg at det er mye å gjøre for å forbedre ytelsen til telefonen ytterligere og prøve å optimalisere batterilevetiden. Spesielt på ytelsessiden av ting var det etter min mening veldig lavt hangende frukt i form av mulige endringer som ville ha nytte av brukeropplevelsen.

Fokuser på ytelse

For denne andre delen satte jeg meg om å prøve å gjenopprette den beste ytelsen som mulig og tilsvarer Snapdragon 845-varianten av Galaxy S9, mens du fortsatt holder øye på batteriets levetid.

Samsung Galaxy S9 (E9810)
Kjernekomparasjon og Changelog
VersjonEndringer og notater
Offisiell firmwareSom sendt- Lageroppsett og oppførsel
- Single Core M3 ved 2704 MHz
- Dual Core M3 ved 2314 MHz
- Quad Core M3 ved 1794 MHz
'CPU Limited
Modus'
- Valgfri Samsung-definert CPU-modus i innstillinger
- CPU begrenset til 1469 MHz
- Minnekontroll ved halvhastighet
- Konservativ planlegger
Tilpasset Config 1- Start med 'Som sendt' firmware
- Fjern stikkontaktmekanismen
- Begrens M3 frekvens topp til 1794MHz ved enhver lasting
Tilpasset Config 2
(Kjernekilde)
- Øk liten kjernefrekvens til 1950MHz
- Heve stor kjerne minimumsfrekvens til 962MHz
- Tilpass EAS kostnadstabeller basert på målt volumkraft
- Flett planlegger oppdateringer til 4.9-eas-dev (Opp til Jan18)
- Backport PELT util_est og bruk den
- Backport PELT decay rate endres til 16ms
- Tilpass / deaktiver ikke lenger nødvendig Samsung plan (util) mods
- Mindre tilpassede modifikasjoner for tuning
Tilpasset Config 3- Øk stor kjernefrekvens til 2314MHz og relevante justeringer

Som et utgangspunkt fortsetter vi videre hvor vi sluttet i del 1, som var ekstremt grei, da de eneste endringene var fjerning av alle boostfrekvenser over 1.8GHz på M3-kjernene og deaktivering av kjernen / hotplugging-driveren på nettet.

I den opprinnelige anmeldelsen var det mest åpenbare problemet jeg identifiserte med hensyn til å påvirke ytelsen til telefonen, den måten enheten var ekstremt treg på når det gjaldt oppskalering i frekvens, samt å migrere tråder på de store kjernene. De opprinnelige verdiene jeg beskrev, var rundt 410ms for en konstant kontinuerlig arbeidsbelastning for å faktisk nå den maksimale frekvensen til de store kjernene. Dette var en flott kontrast til 65ms av Snapdragon 845-varianten. Setter alle andre ting til side dette er det som begrenser den interaktive ytelsen til Exynos 9810 mest, så naturlig er det det vi vil fikse først og fremst.

Planlegger historie rundt EAS

Som en liten backstory, siden big.LITTLEs introduksjon for flere år siden, har det største målet for ARM vært å få SoC-forhandlere til å kjøre heterogene CPUer med en smart planlegger som vil være klar over de ulike CPUens ytelses- og energibehov. Dette var et fint mål å ha, men veien for å komme dit har etter min mening ikke vært noe rot. ARMs tilnærming var å forsøke å gjøre arbeidet i Linux-kjernen oppstrøms eller i Linaro-arbeidsgruppekjernen. Dessverre i løpet av årene og forsinkelser mye av den sprøytenarkomanen som energibeskrivende planlegging (EAS) ville bringe, endte opp med en fizzle når det kom til frakt kommersielle enheter. Jeg tror Qualcomm var på ballen her som selv så tidlig som 2015 for Snapdragon 810, og vi har dekket omfattende hva selskapet prøvde å gjøre for å løse problemer knyttet til EAS.

En nøkkelkomponent for å muliggjøre planlegging på tvers av heterogene CPUer er muligheten for planleggeren å faktisk kjenne aktiviteten og belastningen av individuelle oppgaver, i stedet for bare å vite den generelle CPU-utnyttelsen. Hvis du kjenner en enkelt oppgaves belastning, kan du gjøre beslutninger om å bestemme beslag på hvilke CPU-kjerner som skal plasseres. Dette ble opprinnelig implementert gjennom PELT-mekanismen (Per-entity load tracking) i Linux-kjernen og er det som ble brukt for migrasjonsbeslutninger både i HMP og EAS-planlegging.


Exynos 9810 Gulvplan. Bildekreditt TechInsights

Et annet langvarig mål for Arm og Linux-fellesskapet var å integrere CPU-frekvensvalglogikk innenfor planleggeren, i stedet for at det var en egen mekanisme. Dette ble først forsøkt i et prosjekt kalt schedfreq, og er nå fullt integrert i en ny guvernør kalt schedutil. Igjen er implementeringstidsskalaen vi snakker om her, flere år, mens vi samtidig ser at flere enhetsgenerasjoner blir levert med et utall av løsninger.

S.LSIs Exynos-brikkesett spilte det trygt, og opp til Exnyos 9810 valgte selskapet bare å holde seg til en HMP-planlegger med en separat, interaktiv cpu-frekvensguvernør. Huawei Kirin-brikkesett sender med EAS, men selv med de nyeste enhetene som P20, forgår selskapet planleggeren CPU-frekvensregulatorer og faller tilbake til en tradisjonell interaktiv (med meget gode resultater). I mellomtiden har Qualcomm avansert sin tilpassede implementering og tatt en annen tilnærming kalt WALT (Vinduassistert lastsporing) som er langt mer lydhør overfor PELT. På Snapdragon 835 og 845 er dette kjernemekanismen som sikrer den beste ytelsen når det gjelder planlegging og valg av CPU-frekvens.

Original artikkel

relaterte innlegg

Legg igjen et svar

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.