REMOVED
- Thread starter MBQ_
- Start date
- Status
This is fantastic ... With this guide governors dont have secret anymore :thumbup:
Good job
Sent from my Galaxy Nexus using xda app-developers app
Thank you very much Anarkia. If you have anything to add/teach me/us, please do so!! I'd love to learn some more from you.
La ringrazio molto il mio amico! Io vi tenderemo la mano a te quando ne avete bisogno.
Exactly what I was going for. You're very welcome my friend. I will be adding more as often as I can. I'm a firm believer in the phrase "If you can't explain it simply, then you don't know it well enough."
Edit: Changed up the OP a little. I will inform you guys whenever the OP is changed.
Last edited:
Heck yeah!!! This guide is now STICKIED!
Huge thanks to 'Jonny' for stickying it! I couldn't be any more grateful.
Edit: Fixed some spelling errors in the OP
Edit 2: Fixed more spelling errors in the OP and changed up some words here and there
Huge thanks to 'Jonny' for stickying it! I couldn't be any more grateful.
Edit: Fixed some spelling errors in the OP
Edit 2: Fixed more spelling errors in the OP and changed up some words here and there
Last edited:
Just a couple corrections. The original x governors that imoseyon did for the thunderbolt were the regular governor with a screen off max speed set.
There was a v2 of interactiveX that offlines a core on screen off. AFAIK that never happened for ondemandX.
The design of Wheatley was to maximize time in the c4 state. The rest looks OK.
Sent from my Galaxy Nexus using Tapatalk 2
There was a v2 of interactiveX that offlines a core on screen off. AFAIK that never happened for ondemandX.
The design of Wheatley was to maximize time in the c4 state. The rest looks OK.
Sent from my Galaxy Nexus using Tapatalk 2
Thank you.Undoubtedly the most useful thread out here.
A
I knew about the c4 thing, but didnt want to include it, trying to keep it as simple as possible.
Thank you for your corrections. I will change them and give you credit
Thanks. But as this is a galaxy nexus forum the interactiveX v2 governor which you had described originally should be included as the old style interactiveX doesn't exist on the galaxy nexus.
Sent from my Galaxy Nexus using Tapatalk 2
gianton
Inactive Recognized Contributor
Thank you. Ill change it.
Okay, thank you!
Sent from my Galaxy Nexus using xda premium
I have changed PegasusQ up a little and changed InteractiveX to interactiveX(v2) (Thanks to the 2 users that helped out)
I'll be adding more governors and organising the OP later tonight when I get home. I'll most likely add I/O schedulers later today as well.
Sent from my Galaxy Nexus using xda premium
I'll be adding more governors and organising the OP later tonight when I get home. I'll most likely add I/O schedulers later today as well.
Sent from my Galaxy Nexus using xda premium
* the OP's structure has been changed a little bit. If enough of you don't like it, I'll change it back
Sent from my Galaxy Nexus using xda premium
Sent from my Galaxy Nexus using xda premium
Thank you for the guide. I was thinking on this and this thread came right on time
I'm glad to hear that.
OP has been changed a little.
I added information on the 'Lazy' governor.
I still have many I need to add. I'll be adding the 'Nightmare' governor soon. I need to use it, and read up on its github so I can know more about it. And after that, I'll add the basic I/O schedulers.
Sent from my Galaxy Nexus using xda premium
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
14
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.
And the max screen off profile is what? It's maximum frequency the CPU is allowed to.
No it doesn't.
Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency.
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.
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.
No.
No, it means that it improves battery by increasing the time spent in the C4 low-power state.
As any other governor.
Wakelocks have nothing to do with governors.
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.
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?10Re: [GUIDE] CPU Governors, TCP algorithms, Android Tips, & IO Schedulers: In my Own W
Actually you should care because you're posting mostly wrong information while others are blindly following.
I rember reading up on governors in the link Andrei posted and from another older source long ago and comparing what I understand from useing all those governors and reading up on each of them with what u wrote in your guide is totally different. I can see you're trying to simplify it for everyone to understand in your own way but its not exactly correct and can be confusing cause somethings you mention are unrelated.
Sent from my GT-I9300 using xda app-developers app9Back 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-Captain8Oh, I forgot to tell you about IO schedulers.
Linux (the kernel) was written in a time where spinning disk hard drives were the norm (yeah, they're still working on it, but bear with me here). The problem with these hard drives is that while they can do a linear read with pretty amazing speed, they suck at random reads. This is because there is an arm with a read/write head at the end that has to swivel around to where the data is on the disk, and then it has to wait for the right data to spin under the arm for it to read. This swiveling and waiting is called seeking, and the time it takes to do is called seek time.
When you have a lot of concurrent reads going on (multiple things being read at the same time), this means that the data throughput grinds to a near stop because the head is moving around all the time.
IO schedulers try to optimize this by grouping up nearby reads so fewer costly movements have to be made. There's a few different takes on this, so let me explain a really simple one: You start at the inside of the disk. Sort all the queued reads into order from inside to outside of the disk. Then do them all. Done. Now move the head back and do it again (or start from the other end). Less time is spent moving, more time is spent reading data. Or with an example:
Say you want to read blocks 18, 94, 19 and 46. If you them in the order given you have to seek after 18 to 94, then almost all the way back to 19, then up to 46. That's 3 movements. Now if you reorder them, you get 18, 19, 46, 94. You only have to move twice now, from 19 to 46 and then to 94. That's faster.
Other schedulers try to anticipate reads (you read this part, you probably want the next part so we will wait a really short while to see if you do, then move on). The deadline scheduler tries to reorder reads for optimal access but aims to process each read within a certain time of it being queued. Really smart people have worked hard on these schedulers, and they're very cool pieces of code.
"But borizz27, there's no hard drive in my phone, it's all solid state memory with almost no seek times!" You're right. There isn't. "Then what's the point of the scheduler?" There isn't.
You'd be hardpressed to find differences between the No-Op scheduler (which does nothing, no op meaning No Operation) and any other scheduler on flash memory where the seek time for the next block of data in a linear read is the same as for the next block on the "other side" of the drive. This very fast seeks is the same reason you don't have to defragment SSDs, by the way.
