Improving The Exynos 9810 Galaxy S9: Part 2 - Catching Up With The Snapdragon
by Andrei Frumusanu on April 20, 2018 9:00 AM EST- Posted in
- Mobile
- Samsung
- Smartphones
- Exynos 9810
- Exynos M3
- Galaxy S9
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 Mode' |
- 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.
Facebook
Twitter
RSS
76 Comments
View All Comments
N Zaljov - Sunday, April 22, 2018 - link
For this part, Spock should‘ve used a tunnel bore instead of a mere chainsaw, because a chainsaw doesn‘t seem to accomodate the right amount of „POWER!“ that one would require in order to deal with Samsung‘s crapload of shady implementation. SCNRdjayjp - Friday, April 20, 2018 - link
Wow, amazing work. The definition of above and beyond. I would submit this data to Samsung.StormyParis - Friday, April 20, 2018 - link
Fascinating. Thank you !mad_one - Friday, April 20, 2018 - link
Lovely article!Software can still play a part in the web workloads, as the Javascript and browser engines are probably better tuned for the ARM cores. Of course tt could also be the M3 core struggling to extract enough ILP out of the branchy and cache unfriendly JS code, ARM has certainly tuned their cores for this over the years.
repoman27 - Friday, April 20, 2018 - link
Outstanding work, and much appreciated. Thank you, Andrei!I fully recognize that one only has so much time to commit to writing pieces like this, and that it requires a fair amount of personal interest in the subject matter at hand to do it right. However, it would be great to see Anandtech do a deep dive into the iPhone battery issue. Obviously Apple is intentionally opaque regarding a fair amount of the iPhone and iOS internals, which would make it somewhat more challenging. But I have yet to see anyone publish anything that even quantifies the basics of the reduced performance modes introduced by the various software updates. I can't imagine it would be too hard to figure out what the maximum clocks are with a new battery vs. what appear to be four distinct lower performance modes, or to determine what metrics are used to trigger those modes. Maybe the folks at the kiosk that does aftermarket battery replacements at the local mall would be willing to set aside a box of pulled batteries for testing? Such an article would arrive late as far as the media cycle is concerned, but this is an issue that continues to affect hundreds of millions of people worldwide.
A few years back, Brian Klug used to catch a lot of flack for being biased, before he (and Anand) left to join Apple. And maybe you'll end up at Samsung in the future, like Kristian. But while I think your tone was quite even handed and appropriate in this article, you seemed much more inclined to denounce Apple as deserving of a class-action lawsuit before doing any in-depth testing in regards to their recent power / performance issues. In your opinion, what is the appropriate response from Samsung in this situation? I mean, obviously pushing out a software update that improves performance would be a good start, but should owners of Exynos 9810 variants of the Galaxy S9 sue for damages and extract their pound of flesh?
BurntMyBacon - Monday, April 23, 2018 - link
@repoman27: "But while I think your tone was quite even handed and appropriate in this article, you seemed much more inclined to denounce Apple as deserving of a class-action lawsuit before doing any in-depth testing in regards to their recent power / performance issues."I think the difference in tone reflects the difference in situation. In Samsung's situation, the product came to market with a set level of performance and battery life. Very early in the lifecycle of the product, It was discovered that better software would improve their situation to a more or less extent on one or both fronts. In Apple's situation, the product came to market with a set level of performance and battery life. After a certain time period and as a direct result of a software update, performance suddenly and inexplicably (until it was investigated) dropped for older phones (more cycles on the battery).
Samsung's situation left their solution looking immature at best and their engineers looking incompetent at worst. In either case, their misstep appears to be unintentional and only serves to hurt sales of a new product. Apple's situation left them looking misguided at best and abusive(?) at worst. In either case, their actions appear to be intentional (well meaning or not). The actions only affect phones later in their life cycle and, whether as an unintentional side effect of their actions or as the primary goal of their actions, Apple stands to gain by virtue of prompting upgrades. Some people tend to believe the upgrades were the primary goal due to Apple's locked in ecosystem design and marketing strategy, but it could just as easily have been an (un)fortunate side effect of them trying to mitigate another potentially serious blemish to their user experience. Perhaps a case of the cure being worse than the disease. Like you, I wouldn't mind a more in depth look at the situation that could help clarify this.
In any case, I think the difference in tone comes down to the clear lack of intention on Samsung's part (they don't benefit from this) and potentially well meaning but certainly intentional actions on Apple's part.
B3an - Friday, April 20, 2018 - link
Excellent article Andrei. One of the best on here in a long time.Glad i got a import Snapdragon S9+, because it seems no software update will ever properly fix the poor battery life and *actual daily usage* performance of the Exynos version. Absolutely pathetic how poorly Samsung handled all this though. So many poor decisions. Honestly the people responsible need to be fired. People shouldn't have to go out of their way to buy imports.
serendip - Friday, April 20, 2018 - link
This article will probably be used as a chainsaw by Samsung top management to get rid of everyone who screwed up the Exynos S9. It's sad how seemingly chasing synthetic benchmarks led to bad decisions from chip design onwards.madurko - Saturday, April 21, 2018 - link
AFAIK they are comparing the smaller S9 Exynos (which has 3000mAh battery) vs. S9+ S845 US version (3500mAh). So the battery life obviously will be better with the bigger bro. But, anyway, this doesn't make the exynos version any better.mczak - Friday, April 20, 2018 - link
Very interesting article indeed.I agree the M3 core looks a bit oversized for a smartphone - but a tweaked version of it on 7nm might fare a lot better. For this generation, it definitely wasn't worth the effort over standard A75.
And, by the looks of it, recognizing the power issues, samsung made things worse with an inadequate scheduler.
I wonder if actually the SD845 could get better battery life at very little performance cost by disabling the highest frequency state - that sure looks inefficient as hell. (Albeit that could only widen the battery life gap between the two S9 versions...).
The discrepancy between web tests and microbenchmarks (and spec) in efficiency is also quite interesting - while I'd agree it might be more difficult to extract good IPC of these web tests (putting wide cores at a disadvantage) apple seems to have successfully done so, though I'm ignoring if through software or hardware means.