[Kernel][Apr 26] Perseus

This is a direct port of my kernel on the international I9300 Galaxy S3 and sidekick to the international N7100/5 Note 2 kernels.

Recap of features:

• CPU overclocking up to 1.8GHz and undervolting from 600mV to 1400mV.
• GPU overclocking and undervolting.
• GPU scaling reworked.
• Screen sharpness and colour modifications.
• Extended Pegasusq and improved Performance governors.
• Removed Touch Booster and replaced with custom Flexrate mechanic.
• Improved scheduler power management for improved idle residencies on auxiliary CPUs.
• USB charging rate limit increased to 900mA.

This is supposed to be merely a proxy thread. Please refer to the N7100/5 thread for full changelogs, explanations, bug-reports and other issues. Kernel for specific device versions will be posted here.

This kernel is for the North American T-Mobile variant SCH-T889. Versions for other variants are found in their respective forums.

Ashtear said:

I checked the original thread, but it's 100 pages long; It'd take me forever to go through it. I like understanding the settings so I can custom tailor things to my liking; and the variable names themselves aren't very indicative of what they change to someone who hasn't seen them before. But if I can't find a table showing the variables and what they represent, then I hope at least I can get some help with a specific change I'd like to do.

I ask because I am noticing a bit of a pause when it ramps up the processor from idle. I notice it most when I swipe the home screen using ADWLauncher EX. The first swipe sort of chugs a bit, but afterwards it becomes glass smooth, so I figure it's a ramping issue where the kernel's wound down the cores to rest and when I interact with it it's not winding them up again fast enough; probably not stepping up fast enough.

I want to change the settings a bit so that in the initial step it'll wind up over what's necessary, and then wind down to what's needed. It'll improve apparent response time, and with how much this battery lasts, spending a bit more is not an issue to me. Any idea or help on doing this change will be very appreciated.

Thanks for any help, and my apologies if this has been answered before; the forums are a bit hard to navigate sometimes.

Click to expand...

Click to collapse

I guess I had to write this some time or another. I just also put this into the main thread.

sampling rate
The default time in-between governor scaling "ticks" where the governor checks CPU load and triggers its scaling logic. Measured in milliseconds (ms).

up threshold
The threshold percentage of load from the last sampling window in which the governor triggers its up-scaling logic.

sampling down factor
If the up-scaling logic reaches the max policy; i.e. the maximum allowed frequency, the governor will disregard all logic for x amount of samples and stay at that frequency until we do another scaling sample.

ignore nice load
Processes with higher priorities can have an augmented reported load value, but we can differentiate this and ignore them if this is checked. Keep it at 0.

io is busy
I/O interaction is seen as a CPU load bearing activity. This isn't true for our architecture so keep it at 0.

down differential
The CPU down-scaling logic threshold is triggered if load is less than (up threshold - down differential). The down differential acts as a buffer so that we don't uselessly scale back up in near threshold level loads. If the down-scaling conditions are met, the CPU will take the current CPU load and derive the next best frequency that would accommodate that frequency without triggering an up threshold.

freq step
When the up-scaling logic is triggered the governor dictates the CPU to raise its frequency by (max policy * (freq step / 100)). If max policy is currently 1600 and freq step 21%, it will scale 1600 * 21% = 336. We have a 100MHz grained frequency table so it rounds up to the next 100MHz, 336 becomes 400. If we're idling at 200MHz and the up-scaling logic gets triggered with the above settings, the next frequency will be 600MHz.

cpu up rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring up a CPU.

cpu down rate
The amount of samples the hotplug logic will collect before it makes a hotplug decision to bring down a CPU.

up nr cpus
If the hotplug logic decides we need to bring CPUs up, the amount of CPUs we bring up at once is being dictated here.

max cpu lock
The maximum allowed amount of CPUs allowed to be up at the same time.

min cpu lock
The minimum allowed amount of CPUs allowed to be up at the same time.

hotplog lock
If set other than 0, locks the CPU up count at the specified amount.

dvfs debug
DVFS and hotplug debug is printed out in /proc/kmsg if this is enabled.

hotplug freq x y
Hotplug frequency threshold which decide if we should trigger a hotplug-up or a hotplug-down. X marks the current amount of cores. Each state has a trigger-down (Y = 0) or a trigger-up (Y = 1) condition.
Example: "hotplug freq 3 0 500000" If there are currently 3 cores up, and the frequency gets below 500MHz and the hotplug rq 3 0 conditions for this state are met too, then bring down the core count to 2.

hotplog rq x y
Similar to the hotplug freq conditions in syntax, only that here we are measuring the amount of threads waiting in the kernel runqueue as opposed to frequency. The kernel runqueue is a queue where threads are waiting to be executed. Every cpu up rate or cpu down rate amount of samples, we accumulate the average snapshots of amount of threads in every sampling window. The value itself is this average, just in integer form multiplied by 100. If set to 175 for example, we need to have at least 1.75 threads running over the last cpu-(up/down)-rate * samples to trigger the condition. Live statistics can be extracted by enabling dvfs_debug to see this.

up threshold at min freq
We have the scaling frequencies divided in two parts: ones governed by up_threshold and ones governed by up_threshold_at_min_freq. We want the CPU to get out of the lower frequency states faster to improve fluidity, and also to improve power consumption as the lower power states are more inefficient in perf/power for fixed load tasks over time. The same logics apply as with up_threshold.

freq for responsiveness
Frequency threshold below which up_threshold_at_min_freq is taken instead of up_threshold.

flexrate enable
Enable flexrate requests. Flexrate requests temporarily dramatically raise the sampling rate / lower the sampling period.

flexrate forcerate
Ignore in-putted values given to the governor and use this instead as the accelerated rate.

flexrate max freq
Frequency threshold above which flexrate requests are ignored.

flexrate num effective usage
A statistic of amount of samples taken at the accelerated rate.

lcdfreq enable
Enable LCD frequency scaling.

lcdfreq kick in down delay
The amount of samples below kick-in-freq the CPU must reside for it to switch to the lower display frequency.

lcdfreq kick in freq
The threshold frequency below the CPU must be for the display to switch to lower display frequency.


And for what it matters, I find Nova Launcher the smoothest of them all.

Important security update in v29. Please update.

Updated. Please read the changelog in the main thread.

Mizanari_Kae said:

Well I willz say this I don't run my phone hot or until it get warm, I have done tests at different times Using Antutu.... and I just downloaded the app youve mentioned to run a test on stock kernal to do another light comparison and I note seeing the 58 fps oncreen one of the test and 67 off the results, im just simply glancing over, and by the way my past htc phones used to hit the same 58 to 61 fps until ived gotten a better kernal, im not a expert or anything but I do think its funny that I see the same numbers even when I use a different apps, but any that was the stock kernal, I will be switching back to yours, by th why? do you think my phone is hot right now? not trying to be funny seriously what is too hot to thermald? Everytime I used the performance gov at what I think is normal temperature I get that 8000 score

Sent from my SGH-T889 using xda premium

---------- Post added at 05:09 AM ---------- Previous post was at 04:50 AM ----------

And lofl here comes another test with your lastest kernal version, the only thing I done on this phone in the past few hours is what I have just mentioned in my previous post my phone is not hot or warm to the hand and I do not have to big stupid case on it to where I cant feel heat, ON performance governor I gotten a score slighty over 9000 thousand a new world record but it should be near double that,...... second I used your glbench and guess what the same results buddy 58 fps onscreen and 69 off... are you testing this? so glbench and antutu bench says the same thing, so we cant blame antutu for not testing the graphics correctly, so seriously pal I think you should look at your work again with all do respect to you and your hard work, because in the end I can't do what you do, and I appreciate you devs, however as I mentioned in my very first post I hardly say anything, and when I do its something good, something isnt right I dont know what it is, you are the man and im nobody, what I do know is antutu and glbench throwing back the same numbers and my phone is not hot, im running a stock rom like always lightly modified with your kernal

Sent from my SGH-T889 using xda premium

Click to expand...

Click to collapse

You either have power savings mode turned on or there is something else wrong in your side settings wise. The kernel is fine. Also the benchmarks you did were perfectly normal, and you're just pulling those One S scores out of your ass:

http://www.glbenchmark.com/compare....ified_only=1&D1=Samsung GT-N7100&D2=HTC One S

I cannot make the phone break the VSync barrier, I already explained this.

I would ask if you stopped posting as you're babbling about non-existent issues and reading your writing style makes my eyes hurt.