Following our review of the Galaxy S9 there’s been a lot of discussion about both the performance and battery life of Exynos 9810 variants of the Galaxy S9. In the original review I had identified a few key issues with the platform for which I had deemed to be the most negatively attributing to the bad characteristics of the phone. In a first piece following the review I did a few minor changes to the kernel which already seemed to have benefited battery life in our web browsing test, and slightly changing the performance characteristics of the phone for the positive.

In that previous article I noted that there’s a lot to be done to improve the performance of the phone further and trying to optimise battery life. Especially on the performance side of things there were in my opinion very low-hanging fruit in terms of possible changes that would benefit the user-experience.

Focusing on Performance

For this second part I set about trying to recover the best performance possible and matching the Snapdragon 845 variant of the Galaxy S9, while still keeping an eye on battery life.

Samsung Galaxy S9 (E9810)
Kernel Comparison and Changelog
Version Changes and Notes
Official Firmware As Shipped - Stock setup and behavior
- Single Core M3 at 2704 MHz
- Dual Core M3 at 2314 MHz
- Quad Core M3 at 1794 MHz
'CPU Limited
- Optional Samsung-defined CPU Mode in Settings
- CPU limited to 1469 MHz
- Memory controller at half-speed
- Conservative Scheduler
Custom Config 1 - Start with 'As Shipped' Firmware
- Remove hotplugging mechanism
- Limit M3 frequency peak to 1794MHz at any loading
Custom Config 2
(Kernel source)
- Raise little core frequency to 1950MHz
- Raise big core minimum frequency to 962MHz
- Adapt EAS cost tables based on measured perf & power
- Merge scheduler patches to 4.9-eas-dev (Up to Jan18)
- Backport PELT util_est and use it 
- Backport PELT decay rate change to 16ms
- Adapt/disable no longer needed Samsung sched(util) mods
- Minor custom modifications for tuning
Custom Config 3 - Raise big core frequency to 2314MHz & relevant adjustments

As a starting point we’re continuing on where we left off in part 1, which was extremely straightforward as the only changes were the removal of all boost frequencies above 1.8GHz on the M3 cores and disabling the online core / hotplugging driver.

In the original review the most evident issue that I identified in terms of badly affecting performance of the phone was the way the device was extremely slow in terms of scaling up in frequency, as well as migrating threads onto the big cores. The original values I described were around 410ms for a steady state continuous workload to actually reach the maximum frequency of the big cores. This was a great contrast to the 65ms of the Snapdragon 845 variant. Setting all other things aside this is what was limiting the interactive performance of the Exynos 9810 the most, so naturally it’s what we want to fix first and foremost.

Scheduling history around EAS

As a little backstory, ever since big.LITTLE’s introduction several years ago the biggest goal for ARM has been to have SoC vendors run the heterogeneous CPUs with a smart scheduler that would be aware of the various CPU’s performance and energy characteristics. This was a fine goal to have but the road to get there has been in my opinion nothing short of a mess. ARM’s approach was to try to do the work in the upstream Linux kernel or within the Linaro workgroup kernel. Unfortunately over the years and delays a lot of the hype that energy aware scheduling (EAS) would bring ended up with a fizzle when it came to shipping commercial devices. I think Qualcomm was on the ball here as even as early as 2015 for the Snapdragon 810, and we’ve covered extensively what the company was trying to do to resolve issues relating to EAS.

A key component to enabling scheduling across heterogeneous CPUs is the ability for the scheduler to actually know the activity and load of individual tasks, instead of only knowing the general CPU utilisation. If you know an individual task’s load, then you can make batter scheduling decisions on which CPU cores to place it. This was originally implemented through the PELT mechanism (Per-entity load tracking) into the Linux kernel and is what was used for migration decisions both in HMP and EAS scheduling.

Exynos 9810 Floor Plan. Image Credit TechInsights

Another long-running goal of Arm and the Linux community was to integrate CPU frequency selection logic within the scheduler, instead of it being a separate mechanism. This was first attempted in a project called schedfreq, and is now fully integrated into a new governor called schedutil. Again the implementation time-scale we’re talking about here was several years, while at the same time we’re seeing several device generations being shipped with a myriad of solutions.

S.LSI’s Exynos chipsets were playing it safe, and up to the Exnyos 9810 the company just chose to stick to a HMP scheduler with a separate interactive cpu frequency governor. Huawei Kirin chipsets ship with EAS, however here even with the latest devices such as the P20, the company foregoes the scheduler CPU frequency governors and falls back to a traditional interactive one (with very good results). Meanwhile Qualcomm has advanced their custom implementation and taken another approach called WALT (Window-assisted load tracking) that is far more responsive to PELT. On the Snapdragon 835 and 845 this is the core mechanism that assures the best performance in terms of scheduling and CPU frequency selection.

Scheduler mechanisms: WALT & PELT


View All Comments

  • Andrei Frumusanu - Saturday, April 21, 2018 - link

    It's not a replacement; they serve different purposes. Reply
  • The_Assimilator - Saturday, April 21, 2018 - link

    A single tech writer with some smarts is able to do what a tech conglomerate with multiple billions of dollars can't. That is absolutely fucking pathetic on Samsung's part; I used to think they were just incompetent, but to be able to design and fab their own CPUs, yet not provide appropriate working drivers for that CPU? Words quite honestly fail me. Reply
  • BurntMyBacon - Monday, April 23, 2018 - link

    An alternate view is that they have great teams for chip design (though perhaps not as much this one), semi-conductor fabrication, and phone hardware integration., but not particularly good (being kind) teams for their software/firmware development. Reply
  • johnnycanadian - Saturday, April 21, 2018 - link

    And the verdict is ... if you want the best Android experience, either pick up a Pixel 2 XL or wait a few months for the P3. If you want the highest performing smartphone, tolerate Apple and the never-quite-works-properly Siri and their gimmicky fashion-first business model. I expected better out of Samsung ... The Note9 is supposed to be quite an evolution ... hopefully enough that I can be convinced to trade in my Note5. As for everyday use, my Pixel 1 XL is still running brilliantly and there simply isn't enough of a performance delta to risk a third-party Android build that may or may not receive OS updates 24 months from now. Reply
  • santz - Saturday, April 21, 2018 - link

    thank you for the excellent writeup. I just hope the Note 9 will not have exynos for their international version. Reply
  • Seattletech - Sunday, April 22, 2018 - link

    Sign me up for
    2 M3
    2 A75
    4 A55
  • N Zaljov - Sunday, April 22, 2018 - link

    Magnificent article, thanks for wrapping everything up in such a detailed manner.

    The more I‘m looking at it, the more I‘m asking myself: „WTF were they smoking when they came up with the ingenieus idea of putting all Meerkat cores into a single clock- & voltage-domain?“. And tbh, even today I can‘t come up with a proper explanation other than „Time to market & saving xtors for the sake of not blowing up the chips budget“.
  • Quantumz0d - Sunday, April 22, 2018 - link

    Another majestic one. As expected from the initial experiment, though I was under the remark that the custom tuning would at least fix up the issue a bit, it did but the performance/efficiency is just bad. Very bad for such a high profile flagship device.

    A pity that this level of SoC should need 4000Mah capacity. It would have been much better for tuning and custom software enthusiasts and considering the constant high performance the voltage/power scaling is fine so vs the SD845 this SoC won't kill the total endurance of the battery fast. That's the only good thing of 9810 custom tuned/stock vs 845. But the XDA developer community and the top devs will get much more resources to work with with ease on the other phones with 845 platform like Pixel 3 or OP6 (Unfortunate Notch B$) don't have hopes on HTC as their 10 was a fail even with optimization the efficiency was off small battery and WiFi issues. OP3(T) and 5T seem the best choice for now.

    Much thanks Andrei for this, superb analysis and thanks for letting us know about the EAS too, that was total gold. I needed that. I guess I will pass this. I don't want another 6hr SOT, OP3 barely has 3-5 and 6 is super bad with custom tuning that too after a gap of 1Yr. Will wait for the next Exynos if it has a headphone jack / OP7.

    And please keep this work coming going forth, don't leave us in the dark, Ofc it would be great if you get a good opportunity but we need you.

    Thank you again Andrei.
  • Azurael - Sunday, April 22, 2018 - link

    On my OnePlus 5, I go from 11 hours SOT (with the standard setup) to about 7 (using EAS+schedutil) and performance in most benchmarks regresses - it clearly needs a lot of work. Reply
  • Spoelie - Sunday, April 22, 2018 - link

    Doesn't seem like someone on XDA is picking up this config yet - would love to try it on my S9. Reply

Log in

Don't have an account? Sign up now