It doesn't do it by default though right? Because I monitored my settings in trickstermod using PegasusQ and both cpu cores are running as normal when my screen is on.
REMOVED
- Thread starter MBQ_
- Start date
- Status
It doesn't do it by default though right? Because I monitored my settings in trickstermod using PegasusQ and both cpu cores are running as normal when my screen is on.
I think it varies from kernel to kernel, because it can be modified to hotplug with the screen on. And it depends on what you're running as well, maybe you had more background apps running than him, so that's why both are remaining on, or maybe your dev changed the governor or forked some changes off of github that the other users dev didn't.. There is so many factors that could be in that situation. Hahah
Sent from my Galaxy Nexus using xda premium
Not 100% sure, I'm going to study up about it, test it out myself, and check out its Gihub before I give you guys any information. I want to make sure its as accurate and correct as possible.
Sent from my Galaxy Nexus using xda premium
Thanks man, only reason I asked is because I keep hearing about it in the AK thread and it's the only one not listed.
Sent from my AOSPA Galaxy Nexus
Glad to hear thatI am very happy seeing this thread..
Thanks man, only reason I asked is because I keep hearing about it in the AK thread and it's the only one not listed.
Sent from my AOSPA Galaxy Nexus
I promise Ill get to it.
Changed:
-Changed the title
-Modified InteractiveX(v2)
-Added I/O schedulers
-Added 'Nightmare' Governor information
-Changed up the info on the 'Lagfree' Governor
Where is the nightmare description? I looked through all the op and do not see it.
*Edit, found it below "Lazy", you need to drop it down one line to be in the right place though.
Sent from my AOSPA Galaxy Nexus
Last edited:
Wow thanks! This is really helpful since I can't wrap my head around CPU Governors. Very informative!
:good:
:good:
Thank you!!
Guys, thank you SO much for all the positive feedback. Its almost overwhelming.
Sent from my Galaxy Nexus using xda premium
My best guess is it'd be a smarter hotplug. Or maybe hotplug with screen on hotplug too. Which hotplug already does.....
I'll look into it
Sent from my Galaxy Nexus using xda premium
Thanks that would be great!! Im a total noob about this stuff Lol
Sent from my Galaxy Nexus using xda app-developers app
My guide is here to help!!! I'll add more by tomorrow night. I'm sure I'll update it throughout the day tomorrow anyways though. Hahah
Sent from my Galaxy Nexus using xda premium
Last edited:
Where is the nightmare description? I looked through all the op and do not see it.
*Edit, found it below "Lazy", you need to drop it down one line to be in the right place though.
Sent from my AOSPA Galaxy Nexus
I fixed it!! Typed it with my phone and didn't realize my mistake until you pointed it out.
*fist bump*
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.
