Hello I used non-fair - mainstream phones a really long time, probably more than 5 years experiences from rooting, custom ROMs and custom kernels and a lot of things around that.
I don’t know what compiler did you used, I guess GCC?
So I used a lot of custom kernels and I though about compiling with this.
1. Compiling with latest Clang + LTO or latest GCC -O2 with graphite? 2. Other optimizations what’s used in custom kernels?
Here is a list of stuffs what I think it the best for Fariphone kernel:
Follow linux kernel upstream
Great for security and bugfixes inside the linux kernel.
More steps for GPU clocks and Adreno Idler Support
Zeus kernel have 19MHz and SiLonT have 133MHz on GPU I think it’s great if nothing moves on screen - reading, watch pictures and save some energy, better battery life.
TCP Congestion Algorithms: Westwood (Default)
Just more stable, reliable, faster Wi-Fi connection.
Clang’s a great compiler in terms of maintainability and speed of compilation, but in terms of code performance the difference is often negligible. Kernels are special in how they don’t use very many complex algorithms. Most of what they do is bookkeeping and hardware I/O. Given ARM kernels are generally compiled against their native CPU already, I don’t expect much of a difference. Nor am I 100^% sure whether, and if so since when Clang(+LTO) is supported for ARM by the kernel.
There really isn’t much of that. Most of it amounts to stripping unused features, which these ARM kernels do a lot more than desktop already.
I’d be a huge fan of following upstream kernels. But it’s largely out of Fairphone’s hands. Qualcomm hasn’t upstreamed all of their drivers, and downstream drivers need frequent porting to remain compatible with the latest kernel. You tend to get a better mileage trying to track an upstream long-term kernel (like 5.10), but when its support ends you’ve probably reached the end of Qualcomm’s support too.
Which steps do the current FP kernel support? Also, dropping the clock doesn’t make much of a difference unless the voltage drops along. At some point the GPUs tolerance to lower voltages just stops. That said, I guess every little helps.
More things in RAM at the cost of more CPU cycles for (de)compression. Whether that’s a win is a toss-up and depends on the use-cases. I don’t use very many apps, so my RAM is hardly ever full even on the FP2.
Sorry, so far I’ve been a bit of a grinch. I’m not saying any of these ideas are inherently bad. Rather that each one of them should really be researched in-depth for their viability and for whether they are actually a net win. The current FP kernel really isn’t bad performance-wise. It’s hard to squeeze a lot more out of it, and the process of doing so must be data-driven.
I think i actually read somewhere that Lineage OS for the FP2 is using a (slightly) newer kernel than the original FP OS but i don‘t know if it is also compiled differently.
These are interesting results, thanks! Of course, this didn’t test GCC+LTO, which GCC supports since version 8 (but perhaps not on the kernel?). And these results don’t necessarily translate to ARM, or the specific ARM core used in the Fairphones. Definitely not to FP2, there’s no chance you’ll get Clang/LTO working on a 3.4 kernel. Not sure about FP3(+), but I’m hopeful it may be possible on the FP4.
Yep I hope so, Clang + LTO is beast, I have Arch Linux with march=tigerlake (because i have tigerlake CPU) + Clang full LTO, my ultrabook is like rocket… xD I hope something similar can be possible with Fairphone.