[Samsung Galaxy S9 & S9+ Cross Device Development] flar2:
I've been testing many variations this week. I think what I've done already is the best solution.

The big cluster on this phone should have a maximum of 1.7 or 1.9GHz. Samsung wanted to boast a higher number, so they made a "hotplug" driver that allows the chip to run at 2.7GHz when only one core is needed. When two cores are active, it drops to 2.3 and when three or four cores are needed, it limits the frequency to 1.7. It can't run all four cores at 2.7 because it consumes too much power and the phone becomes unstable. Reaching those frequencies requires a lot of extra voltage, which the phone can't supply. They are essentially overclocking the phone when there is only one thread on the big cluster.

The default config for ElementalX leaves the Exynos hotplug driver enabled, with frequencies of 2.7/2.3/1.9. This means a very slight boost from 1.7 to 1.9 for multithreaded workloads.

[MENTION=4167023]AndreiLux[/MENTION] disables the hotplug driver and limits the frequency to 2.3. He also backported the latest EAS, changed the cost tables, disabled input boosting, and increased the minimum frequency of the big cluster. Further, he overclocks the little cluster from 1.7 to 1.9. His latest commit is a limiter that looks at total power and caps the big cluster frequencies under heavy load. This is necessary to prevent instability.

How does it compare to ElementalX?

Battery life is close. For me, I was averaging about 12-13%/hr active drain with ElementalX defaults. I got about 14-15%/hr with Andrei's kernel over the weekend.

I couldn't really sense a difference in performance. Both configurations are smooth and snappy. In terms of benchmarks, ElementalX always wins on single thread performance, because it can go up to 2.7GHz compared to only 2.3 for Andrei's kernel. For multicore performance, Andrei's kernel should have a slight edge because it's running 2.3 on all cores vs. 1.9 with ElementalX, and he removes the overhead from Samsung's hotplug driver. However, the capacity limiter tends to reduce frequencies to 1.5 or 1.6 GHz under heavy loads, so ElementalX has a slight edge because it is consistently at 1.9. It is important to note here that allowing all cores to run at 2.3 results in instability on my unit. My phone usually reboots around the 78% mark on the Geekbench benchmark with all cores at 2.3.

To summarize, here are approximate scores with Geekbench 4 (single thread/multithread):

Andrei's latest: 3200/9200

Andrei's latest without the capacity limiter: 3200/9900 (unstable)

ElementalX 1.06: 3600/9400

ElementalX with EAS backports 3600/9300 (slight regression)

ElementalX with EAS backports, hotplug disabled and frequency limited to 2.3: 3200/9900 (unstable)

The power aware capacity limiter that Andrei is working on is a really great idea, and I will be interested to see what he does with it. I experimented with it, to try to create a scenario where 2.7GHz could be maintained for single threaded work, but I couldn't find a happy medium. So I experimented with other types of limiters based on CPU utilization, but still suffered from instability and regressions on single threaded (although I did break 10,000 on Geekbench multithreaded). Ultimately, I came back to something approximating Samsung's default hotplug driver. It is impossible to maintain stability on this chipset without taking into consideration power consumption for both clusters and reducing frequencies appropriately.

Andrei's criticisms of Samsung's hotplug mechanism are valid, but I think at the end of the day, Samsung's solution is pragmatic. It achieves a good balance of battery life, stability and performance. For me, leaving Samsung's hotplug driver enabled allows much better single thread performance and the slight boost to multithread frequencies more than makes up for inefficiency in the hotplug driver. Look at time-in-state stats for the big cluster, you'll see that 2.7 and 2.3 frequencies are used quite a bit in daily usage. The hotplug driver allows us to use those frequencies, where Andrei's solution does not.