Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

---

Originally Posted by Timmyfoxeh

The only CPU gov I'm missing here is Dyninteractive.
Otherwise it's a very well written guide.

Ill add it to the guide soon! Thanks

Sent from my Galaxy Nexus using xda premium

Update:
-Added information on DynInteractive

Update:
-Reverted back to the normal font

OnDemand:

Basically, this Governor will allow your phone to use CPU speeds on demand, meaning.. If you're sending a text, your phone wont require much memory, but if you're playing a graphically intense game, it will use both cores, most likely at your highest set CPU speed, and will idle back down when you finish your game.

No.

It doesn't require much memory? What? CPU governors control CPU frequency, memory has nothing to do with this. Ondemand also has nothing to do with cores as it's not a hotplug aware governor.

Ondemand stands for that it scales up on load in frequency and then detects the load and scales back to a frequency which is fullfills the "demand" of the current load dynamically.

OndemandX:

The same idea of Ondemand, but when the screen turns off, the max screen off profile is 500MHz.

And the max screen off profile is what? It's maximum frequency the CPU is allowed to.

Interactive:

The same idea of Ondemand, but Interactive scales your CPU to the highest frequency faster than Ondemand does.

No it doesn't.

Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency.

Conservative:

Slower CPU scaling, less aggressively as well. For example, lag will occur if using this Governor while running multiple apps, because the idea of this kernel is to be as conservative as possible.

No it doesn't.

Conservative means that it scales conservatively, not that it is conservative. It pretty much very similiar to Interactive in that it scales up and down in frequency steps. It actually can be one of the most aggressive governors out there.

Intellidemand:

An intelligent Ondemand. It acts like Ondemand if the GPU gets busy, but it loads the CPU frequencies up just a tad faster and more efficient than Ondemand.

And what does it do when the GPU is not busy? First of all it is broken in the regard of actually even checking GPU load, which is the one single thing which sets this apart from Ondemand, and has a minimum frequency in such cases. Secondly, it's identical to Ondemand in all other situation.

Wheatley:

One of the favored Governors of users. It is based on Ondemand, but was built with performance in mind, and maxes out c4 time (Simply put: It keeps your phone nice and fast). When opening and running apps, it will ramp up the CPU. Reduced sampling intervals was included as well, and a unique feature of this Governor is the Sampling interval can be lower than the target residency, which prevents wakelocks without hurting battery life.

No.

(Simply put: It keeps your phone nice and fast)

No, it means that it improves battery by increasing the time spent in the C4 low-power state.

When opening and running apps, it will ramp up the CPU.

As any other governor.

and a unique feature of this Governor is the Sampling interval can be lower than the target residency, which prevents wakelocks without hurting battery life.

Wakelocks have nothing to do with governors.

Hotplug:

Based off of Ondemand. It allows a CPU to go offline with minimal usage. When you're sending messages, browsing settings, or other simple tasks, most likely one of your CPUs will be offline, which means in the long run, it will increase your battery life. When your screen goes off, it will shut off a core of your phone, which drastically improves battery life.

Actually when your screen goes off all your cores go off. What it does is that it limits itself to 1 core when doing activity when the screen is off.

PegasusQ:

Samsungs Governor for multi-core phones. Based off of Ondemand. This kernel controls hotplugging as well, but doesn't hotplug a CPU (unless the developer changed the kernel to do so) when the screen is on.

Well does it do hotplugging or not? Yes it does, even without the developer.


I got tired by now and I even left out all the ancient governors. More tomorrow. I hope some people get the point I'm trying to make here, who allowed this to be stickied?

Back on-topic here guys. I don't think AndreiLux intended to come off as saying everything in this thread was wrong, but just wanted to contribute in making sure it was correct. No more post in here about if it was rude or not though, this thread has been derailed enough. Thanks.

~ The-Captain

Originally Posted by The-Captain

Back on-topic here guys. I don't think AndreiLux intended to come off as saying everything in this thread was wrong, but just wanted to contribute in making sure it was correct. No more post in here about if it was rude or not though, this thread has been derailed enough. Thanks.

~ The-Captain

wishing that andreilux post be edited in another way.
thx in advance

Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

---

Originally Posted by The-Captain

Back on-topic here guys. I don't think AndreiLux intended to come off as saying everything in this thread was wrong, but just wanted to contribute in making sure it was correct. No more post in here about if it was rude or not though, this thread has been derailed enough. Thanks.

~ The-Captain

I was waiting for you.

Anyways, MBQ, waiting for whatever corrections/updates you deem fit.

Sent from my Galaxy Nexus using xda premium

Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

---

I notice a difference already with my on screen battery drain from following your guide. Thank you!!!!

I actually missed what happened here, maybe for the better.

Originally Posted by The-Captain

I don't think AndreiLux intended to come off as saying everything in this thread was wrong, but just wanted to contribute in making sure it was correct.

Although certainly not everything is wrong, the vast amount of information is wrong. It's supposed to be a "simple" introduction to things but it severely veers off cliff on several things. The explanations seems to be actually copied, or may I say, "rewritten in OP's own words" (Probably why so much is wrong) from all over the place, with little actual knowledge on the topics. Some of the governor explanations really sticked out as painfully wrong and I corrected some of them.

I doubt OP can actually explain anything in this "guide", as I've said most of it is wrong and copied out of context. The zRam explanation is actually out of this world:

Avoids disk paging, compresses your RAM. Disk paging means the way your phone saves temporary data. It helps with fragmentation of your disk and the physical space, which, over time, keeps speed stable and prevents any system slowdowns.

Disk paging doesn't even exist on a phone, unless you have a custom kernel which supports, and you yourself actually created a swap space. Fragmentation doesn't exist / doesn't matter on solid state memory.

This really shouldn't be a sticky, and people really would be better off following other guides.

Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W

---

Originally Posted by AndreiLux

I actually missed what happened here, maybe for the better.
Although certainly not everything is wrong, the vast amount of information is wrong. It's supposed to be a "simple" introduction to things but it severely veers off cliff on several things. The explanations seems to be actually copied, or may I say, "rewritten in OP's own words" (Probably why so much is wrong) from all over the place, with little actual knowledge on the topics. Some of the governor explanations really sticked out as painfully wrong and I corrected some of them.

I doubt OP can actually explain anything in this "guide", as I've said most of it is wrong and copied out of context. The zRam explanation is actually out of this world:
Disk paging doesn't even exist on a phone, unless you have a custom kernel which supports, and you yourself actually created a swap space. Fragmentation doesn't exist / doesn't matter on solid state memory.

This really shouldn't be a sticky, and people really would be better off following other guides.

Don't care

Thx

Sent from my Galaxy Nexus using xda premium