FAQ - Will be updated as needed.
Q: CPU Frequency Governor, I/O schedulers, what?
A: Here's a good resource that explains a lot about the topic in general and schedulers:
http://forum.xda-dev...d.php?t=1369817
Q: I want different colors, how do I do it?
A: You can use an app such as Trickster MOD, Trinity, Franco, or Glados Control to change these. I prefer to keep them default on my builds because preference varies. (For reference, trinity's default colors are R: 135 G: 135 B: 214, Gamma offset 0/0/0 (I think)
Q: Kernel is randomly rebooting, how can I help?
A: After a reboot, pull /proc/last_kmsg from the device and send it my way.
Q: What I/O scheduler should I use?
A: I haven't really found any real-world difference between any of them. I personally prefer the simpler algorithms of Zen/SIO.
Q: What CPU frequency governor should I use?
A: Entirely up to you. I tend to favor interactive because it's google's governor.
Q: Do all these extra I/O schedulers and cpu frequency governors impact performance or stability?
A: No. I like to keep as many as people will use. If 1 person prefers the conservative governor it'll stay in. There is minimal->no overhead from including extra I/O and/or cpu frequency governors. Therefore, performance+stability will not be affected in the slightest. Choose the one you like, if not sure the default settings are a safe bet.
Q: Why did you create ZenSERIES?
A: It's pretty fun to do, and it's going to make a great pairing with AffinitySERIES, and hopefully several other roms as well.
Q: Do you support any other devices?
A: Working on several others.
Q: What is this "Zen Info" sysfs interface?
A: Probably nothing you care about unless you're a developer looking to do something special with zen. Otherwise, it doesn't affect you and it's for me.
Q: What is this Aaron Carol stuff you added (V(r ), no-op changes, fifo (I wrote a detailed answer already, so wanted to include it in FAQ)
A:
1.) V(R ) is similar to deadline (uses deadlines for fairness). Basically, requests are based on on the distance from the last request/I.E: the next closest request comes first (with penalty of rev_penalty). Naturally, we don't care about the distance from the last request because we're using flash memory (in our case, handling the closest request is nothing but overhead since there is no travel delay) so it doesn't matter where the next request is. I'd say in a nutshell it would be a higher thoroughput/higher latency version of deadline in a typical desktop environment. On our phones, not sure where it would fall. (I removed some unnecessary parts of the algorithm, like choosing closest request/changing head direction, etc.) You may say "Oh, why would you add an I/O scheduler that handles requests like that?" Well, it's not the only one. Deadline/CFQ/BFQ will all sort requests. But the difference between them, in my experience, is usually negligible for real-world tests.
2.) FIFO: Ok, so no-op stands for "no operation". Essentially that means handle requests in order, don't sort them, don't merge them, don't do anything except handle the next request in line. In reality, it actually does some sorting (sorts dispatches, and some requests i think). FIFO is a true "no-op" scheduler. Doesn't do anything, strictly FCFS.
* e.g. We could have 3 requests in the queue. the first one could be very small, second one could be astronomically large, third one can be extremely small. Some schedulers may say, lets do #3 before #2 because it is right next to where we're at and it's very short. Some schedulers may say, lets combine #3 and #2 to make it 1 large request. Fifo doesn't do any of that, it goes in order. Literally first in , first out.
3.) No-op: No-op already exists in the kernel obviously, now it does a bit more stuff. Like I said above, no-op isn't entirely no-op. I have a patch from AC that makes no-op do full merging and sorting. Meaning, it actually will merge some requests if applicable and sort them based on things like priority, size, distance, etc. Other change to no-op is that dispatches are all back-inserted. Meaning added to the back of a stack. Normally no-op sorts dispatches.
Q: What is the zen I/O scheduler?
A: Well, the question that was asked above led me to an analysis of V(R ), deadline, and some others. I already knew, but realized "this is the main feature of V®, but wait it has no benefit to us smartphone users." So I thought about adjusting the way V(R ) handled requests and how it dispatched them (I chose V(R ) because i'd rather not tinker with a scheduler thats official and widely supported). Then I was looking over it, and realized I might as well just write a new one I don't need any of this stuff. So I came up with something awfully similar to SIO, although its a bit simpler than SIO (closer to no-op) and works just slightly different.
- It's an FCFS (First come, first serve) based algorithm. It's not strictly FIFO. It does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones. Other than that, pretty much the same as no-op.
Edited by bbedward, 02 November 2012 - 10:16 AM.
0
