Förbättra Exynos 9810 Galaxy S9: Del 2 - Fånga upp med Snapdragon

Efter vår granskning av Galaxy S9 har det skett mycket diskussion om både prestanda och batterilivslängd för Exynos 9810-varianter av Galaxy S9. I den ursprungliga översynen hade jag identifierat några viktiga problem med plattformen som jag hade ansett vara den mest negativa attributet till telefonens dåliga egenskaper. I en första del efter översynen Jag gjorde några små förändringar i kärnan som redan tycktes ha gynnat batteriets livslängd i vårt webbläsningstest och ändrade ändringar i telefonens prestanda för de positiva.

I den tidigare artikeln noterade jag att det finns mycket att göra för att förbättra telefonens prestanda ytterligare och försöka optimera batteriets livslängd. Särskilt på prestationssidan av saker var det enligt min mening mycket låghängande frukt i form av möjliga förändringar som skulle gynna användarupplevelsen.

Fokusera på prestanda

För den här andra delen försökte jag återställa bästa möjliga prestanda och matcha Snapdragon 845-varianten av Galaxy S9, samtidigt som jag håller ögonen på batterilivslängden.

Samsung Galaxy S9 (E9810)
Kärnkompensation och Changelog
versionÄndringar och anteckningar
Officiell firmwareSom levereras- Lagerinställningar och beteende
- Single Core M3 vid 2704 MHz
- Dual Core M3 vid 2314 MHz
- Quad Core M3 vid 1794 MHz
"CPU Limited
Läge'
- Valfritt Samsung-definierat CPU-läge i Inställningar
- CPU begränsad till 1469 MHz
- Minnekontroll vid halvfart
- Konservativ Scheduler
Anpassad Config 1- Börja med "As Shipped" firmware
- Ta bort hotplugmekanismen
- Begränsa M3 frekvens topp till 1794MHz vid eventuell laddning
Anpassad Config 2
(Kärnkälla)
- Öka liten kärnfrekvens till 1950MHz
- Höj maximal kärnfrekvens till 962MHz
- Anpassa EAS kostnadstabeller baserat på uppmätt prestanda
- Merge schemaläggare till 4.9-eas-dev (Upp till Jan18)
- Backport PELT använder och använder det
- Backport PELT sönderfallshastighet ändras till 16ms
- Anpassa / inaktivera inte längre behövs Samsung-scheman (util) mods
- Små anpassade modifieringar för tuning
Anpassad Config 3- Höj stor kärnfrekvens till 2314MHz och relevanta justeringar

Som utgångspunkt fortsätter vi där vi slutade i del 1, vilket var oerhört enkelt eftersom de enda förändringarna var borttagningen av alla boostfrekvenser över 1.8GHz på M3-kärnorna och inaktiverande online kärn / hotplugging-drivrutinen.

I den ursprungliga översynen var det mest uppenbara problemet som jag identifierade när det gäller att påverka telefonens prestanda väldigt långsamt när det gäller att skala upp i frekvens och migrera trådar på de stora kärnorna. De ursprungliga värdena jag beskrev var runt 410ms för en konstant kontinuerlig arbetsbelastning för att faktiskt nå den maximala frekvensen hos de stora kärnorna. Detta var en stor kontrast till Snapdragon 65-varianten 845ms. Att ställa in alla andra saker åt sidan är det som begränsade Exynos 9810 interaktiva prestanda, så naturligtvis är det vad vi vill fixa först och främst.

Planera historia runt EAS

Som en liten backstory, allt sedan big.LITTLEs introduktion för flera år sedan har det största målet för ARM varit att SoC-leverantörerna driver de heterogena processorerna med en smart schemaläggare som skulle vara medveten om de olika processorns prestanda och energiegenskaper. Detta var ett bra mål att ha men vägen att komma dit har varit enligt min mening inget annat än en röra. ARM: s tillvägagångssätt var att försöka göra arbetet i Linux-kärnan eller i Linaro-arbetsgruppkärnan. Olyckligtvis under åren och förseningar mycket av den hype som energibeskrivande schemaläggning (EAS) skulle ge upphörde med en fizzle när det kom till frakt kommersiella enheter. Jag tror Qualcomm var på bollen här som jämnt så tidigt som 2015 för Snapdragon 810, och vi har omfattat omfattande vad företaget försökte göra för att lösa problem som rör EAS.

En nyckelkomponent för att möjliggöra schemaläggning över heterogena processorer är förmågan för schemaläggaren att faktiskt känna till aktiviteten och belastningen av enskilda uppgifter istället för att bara veta det allmänna CPU-utnyttjandet. Om du känner till en enskild uppgiftsbelastning, kan du göra beslutsfattande beslut om vilka CPU-kärnor som ska placeras. Detta genomfördes ursprungligen genom PELT-mekanismen (Per-entity load tracking) i Linux-kärnan och är det som användes för migrationsbeslut både i HMP och EAS-schemaläggning.


Exynos 9810 planlösning. Bildkredit TechInsights

Ett annat långsiktigt mål för Arm och Linux-gruppen var att integrera CPU-frekvensvallogiken inom schemaläggaren, istället för att den var en separat mekanism. Detta försökades först i ett projekt som heter schedfreq, och är nu helt integrerat i en ny guvernör som kallas schemaläggning. Återigen är implementeringstidskalan vi talar om här flera år, samtidigt som vi ser att flera enhetgenerationer levereras med en mängd lösningar.

S.LSIs Exynos-chipset spelade det säkert, och upp till Exnyos 9810 valde företaget bara att hålla sig till en HMP-schemaläggare med en separat interaktiv cpu-frekvensguvernör. Huawei Kirin-chipset skickas med EAS, men här även med de senaste enheterna som P20, förlorar företaget schemaläggaren CPU-frekvensregulatorer och faller tillbaka till en traditionell interaktiv (med mycket bra resultat). Under tiden har Qualcomm avancerat sin anpassade implementering och tagit ett annat tillvägagångssätt kallat WALT (Window-assisted load tracking) som är mycket mer responsiv mot PELT. På Snapdragon 835 och 845 är detta kärnmekanismen som garanterar bästa möjliga prestanda när det gäller schemaläggning och CPU-frekvensval.

Ursprungliga artikel

relaterade Post

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är markerade *

Den här sidan använder Akismet för att minska spam. Läs om hur din kommentardata behandlas.

Tillbaka till toppen knappen